Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

04 - Agile Software Configuration Management

2,680 views

Published on

Published in: Technology
  • Be the first to comment

04 - Agile Software Configuration Management

  1. 1. AGILE SOFTWARE CONFIGURATION MANAGEMENT
  2. 2. INTRODUCTION2 General conventions and ideas
  3. 3. 3
  4. 4. GOALCONNECTION BETWEEN:1. AGILE-METHODOLOGIES AND CONFIGURATION MANAGEMENT PRACTICES2. TOOLS UTILIZED BY SOFTWARE CONFIGURATION MANAGEMENT PRACTICES Version control Build & Versions deployment numbering managementAgile SCM 4 Release Continuous management integration
  5. 5. NARRATION FROM SIMPLE TO COMPLEX… 5
  6. 6. NARRATION …WITH SIMULTANEOUS ELIMINATION OF EMERGING CONTRADICTIONS 6
  7. 7. REPRESENTATION STREAMLINE DIAGRAMS 7
  8. 8. REPRESENTATION STREAMLINE DIAGRAMS 8
  9. 9. REPRESENTATION STREAMLINE DIAGRAMS 9
  10. 10. REPRESENTATION STREAMLINE DIAGRAMS 10
  11. 11. REPRESENTATION STREAMLINE DIAGRAMS branches releases builds tags merges directories commits 11
  12. 12. BRANCHES INHERITANCE /1.1 /1 /2.0 /1.0 /2 12
  13. 13. BUILDING FROM BRANCH /1 1.0 1.1 1.2 13
  14. 14. EXISTING VERSIONNUMBERING APPROACH 1.2.3 [major].[minor].[build] ARCHITECTURE CONCEPTS PORTING ITERATIONS BUILD MARKETING 14
  15. 15. SIMILAR IDEAS1. Version control for multiple agile teams:http://www.infoq.com/articles/agile-version-control2. Configuration management patterns:http://www.cmcrossroads.com/bradapp/acme/branching/ 15
  16. 16. SIMPLEST SCENARIO16 «2 days for release »
  17. 17. SIMPLEST SCENARIO After several subsequent commits developers want to build application Why?1. It implements functional requirements (bugs/features) or performance requirements2. Build is accessible by the end user:  Building standalone application  Deployment of web-application  Gathering metrics and statistics (integration build) 17
  18. 18. SIMPLEST SCENARIO  Then there is need to make a release  Why?  Release is a special type of a build  But it has specific features: 1. Full implementation of requirements set 2. Quality 3. Usability 18
  19. 19. SIMPLEST SCENARIO SIMPLEST SCENARIO IS… …THE CASE WHEN ALL THESE STEPS DOES NOT REQUIRE TOO MUCH EFFORT «2 DAYS FOR RELEASE» 19
  20. 20. SIMPLEST SCENARIO release ! /trunk 1 ? 2 ? 3 ? 1.0 ? 1.1 ? 1.2 ? 20
  21. 21. MORE COMPLEX EXAMPLE21 Extending the scope
  22. 22. IMAGINE … YOU NEED TO STABILIZE YOUR RELEASE andPROVIDE SIMULTANEOUS DEVELOPMENT OF ANOTHER APPLICATION VERSION 22
  23. 23. BRANCHING FOR RELEASE release merge ! ! /trunk 1 ? 2 ? 3 ? 2.0 ? 2.1 ? 2.2 ? 2.3 ? /1.x 23 1.0 ? 1.1 ? 1.2 ?
  24. 24. BRANCHING FOR RELEASE DID YOU NOTICE? INCONSISTENCY IN VERSIONS NUMBERING!IT MAKES SENSE TO SEPARATE DEVELOPMENT IN TRUNK AND RELEASE STABILIZATION 24
  25. 25. BRANCHING FOR RELEASE /trunk1? 2 ? 3 ? 4 ? 5 ? 6 ? 7 ? 8 ? /1.x /2.x 1.0 ? 1.1 ? 1.2 ? 2.0 ? 2.1 ? 25
  26. 26. EXAMPLE EVEN MORE COMPLEX26 Parallel branching
  27. 27. BRANCHING FOR RELEASEYOU WILL NEED TO BE ABLE TO GO TO THE RELEASE STABILIZATION ANYTIME andDO NOT INTERRUPT ANY OTHER DEVELOPMENT OR RELEASE STABILIZATION 27
  28. 28. BRANCHING FOR RELEASE /2.x 2.0 ? 2.1 ? /trunk1? 2 ? 3 ? 4 ? 5 ? 6 ? 1.3 ? 2.2 ?0.1 0.2 0.3 0.4 0.5 0.6 /1.x 1.0 ? 1.1 ? 1.2 ? 28
  29. 29. BRANCH TYPESIt’s time to think about branch types! ? 29
  30. 30. BRANCH TYPES release branch /2.x x.x 2.0 ? 2.1 ? /trunk x.1 1 ? x.2 2 ? 3 ? x.3 4 ? x.4 5 x.5 ? 6 x.6 ? 1.3 x.7 ? 2.2 x.8 ? no type (it’s just trunk)release branch /1.x 1.0 ? 1.1 ? 1.2 ? 30
  31. 31. EXAMPLE OF THE CASE, WHEN BRANCHES BEGIN TO GROW BY THEMSELVES.31
  32. 32. BRANCH TYPES incompatible changes /2.x 2.0 ? 2.1 ? cannot merge /trunkx.1 1 ? x.2 2 ? 3 ? x.3 4 ? x.4 5 x.5 ? 6 x.6 ? 1.3 x.7 ? 2.2 x.8 ? /1.x 32 1.0 ? 1.1 ? 1.2 ?
  33. 33. BRANCH TYPES Incompatible changes means:  changes cannot be easily merged to the parent branch Example:  deep refactoring (files hierarchy changes)  serious architecture/application structure modification  rewriting application or its part from scratch 33
  34. 34. BRANCH TYPES release branch /2.x /0.2.x 2.0 ? 2.1 ? 0.x.x 0.2.0 0.2.1 /trunk x.1 1 ? x.2 2 ? 3 ? x.3 4 ? x.4 1.3 x.5 ? cannot merge0.x.1 0.x.2 0.x.3 0.x.4 0.x.5release branch /1.x /1.x.x /? /0.1.x 1.0 ? 1.1 ? 1.2 ? support 34 0.1.0 0.1.1 0.1.2 branch
  35. 35. BRANCH TYPES /0.2.x /0.3.x /trunk /1.0.x /0.1.x /1.x.x release branch 35 support branch
  36. 36. SUPPORT VS RELEASE BRANCH Support branch Release branch Does not allow merge  Allows merge with parent with parent branch branch Exists forever  Exists only until stable version is released Child branches are  Child branches are not allowed allowed Cannot have another support branch as child Deprecates merging with 36 child branch
  37. 37. BRANCH TYPES /trunkx.0 x.2 x.4 x.6 x.8 x.11 x.1 1 ? x.3 x.5 x.7 x.9 x.10 experimental branch 37
  38. 38. EXPERIMENTAL VS RELEASEBRANCH Release branch Experimental branch Does not allow child  Allows any number of branches child branches Uses strict branch name.  Name is not restricted at Example: 1.0.x all. Example: new_eng_test Uses own scope of builds  Shares scope of builds numbering numbering between all relative branches Recommended merging  No recommended approach: after each merging approach 38 build/release
  39. 39. CODEBASE INHERITANCE /0.2.x 0.x.x /trunk /2.x.x /0.1.x /1.x.x latest development 39
  40. 40. CODEBASE INHERITANCELatest development should reside in trunk 40
  41. 41. CODEBASE INHERITANCE /3.x.x1.x.x 2.x.x 3.x.x 4.x.x /trunk /2.x.x /1.x.x 41
  42. 42. TYPES OF BUILDS builds pre-alpha alpha (A) beta (B) (PA) releases alpha beta release release release candidate stable (ST) 42 (AR) (BR) (RC)
  43. 43. SCM IN ACTION 1.x.x 2.x.x/trunk PA 1.x.0 1.x.3 2.x.0 A 1.x.1 1.x.4 2.x.1 builds B 1.x.2 1.x.5 2.x.2 /1.x.x AR 1.0.0 BR 1.0.1 RC 1.0.2 1.0.3 releases ST 1.0.4 /1.0.x 43
  44. 44. SCRUM AND SCM/trunkPA/A 1.x.0 1.x.1 1.x.2 1.x.3 1.0.0 1.0.1 demo AR/BR user stories /1.0.x sprint backlog 44
  45. 45. SOURCE CODE REPOSITORY DIRECTORIES HIERARCHY45
  46. 46. DIRECTORIES HIERARCHYPROJECT 46
  47. 47. DIRECTORIES HIERARCHYTAGS 47
  48. 48. DIRECTORIES HIERARCHYSUPPORT BRANCHES 48
  49. 49. 1.x.x 2.x.x trunk PA 1.x.0 1.x.3 2.x.0 A 1.x.1 1.x.4 2.x.1 /tags/builds B 1.x.2 1.x.5 2.x.2 /branches/maintenance/versions/1.x.x AR 1.0.0 BR 1.0.1 RC 1.0.2 1.0.3 /tags/releases ST 1.0.4 /branches/releases/1.0.xНомера 1 12 39 52 73 79 93 112 126 139 140 155 170 193 201 215 230ревизий 49
  50. 50. Afterword AFTERWORD50
  51. 51. 51Thank you for attention!
  52. 52. USEFUL LINKS1. http://www.infoq.com/articles/agile-version-control - agile version control2. http://svnbook.red-bean.com/ - official subversion reference/book “Version Control with Subversion”3. http://www.ericsink.com/ - one of the best blogs about version control4. http://www.versioncontrolblog.com/ - another great blog about version control5. http://better-scm.berlios.de/comparison/comparison.html - VCS comparison table6. http://www.cmcrossroads.com/ - biggest resource about SCM7. http://www.infoq.com/news/2009/03/Continuous-Deployment - about continuous deployment 52

×