AGILE SOFTWARE CONFIGURATION

MANAGEMENT

2

INTRODUCTIONGeneral conventions and ideas

3

𝑠𝑐𝑜𝑝𝑒→∞

4

CONNECTION BETWEEN:1. AGILE-METHODOLOGIES AND CONFIGURATION

MANAGEMENT PRACTICES

2. TOOLS UTILIZED BY SOFTWARE CONFIGURATION MANAGEMENT PRACTICES

GOAL

Version control

Build & deployment manageme

nt

Continuous integration

Release manageme

nt

Versions numbering

scm practices

Agile SCM

5

NARRATION

FROM SIMPLE TO COMPLEX…

6

NARRATION

…WITH SIMULTANEOUS ELIMINATION OF EMERGING

CONTRADICTIONS

7

REPRESENTATION

STREAMLINE DIAGRAMS

8

REPRESENTATION

STREAMLINE DIAGRAMS

9

REPRESENTATION

STREAMLINE DIAGRAMS

10

REPRESENTATION

STREAMLINE DIAGRAMS

11

STREAMLINE DIAGRAMS

branches

tagsbuilds

releases

mergesdirectoriescommits

REPRESENTATION

12

BRANCHES INHERITANCE

/1

/2

/1.1

/2.0/1.0

13

BUILDING FROM BRANCH

1.0 1.1 1.2

/1

14

EXISTING VERSION NUMBERING APPROACH

[major].[minor].[build]

1.2.3

ITERATIONS

ARCHITECTURE

CONCEPTSPORTING

MARKETING

BUILD

15

SIMILAR IDEAS

http://www.cmcrossroads.com/bradapp/acme/branching/

2. Configuration management patterns:

http://www.infoq.com/articles/agile-version-control

1. Version control for multiple agile teams:

16

SIMPLEST SCENARIO«2 days for release »

17

SIMPLEST SCENARIO

After several subsequent commits developers want to build application

Why?1. It implements functional requirements

(bugs/features) or performance requirements

2. Build is accessible by the end user: Building standalone application Deployment of web-application Gathering metrics and statistics (integration

build)

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 set2. Quality3. Usability

19

SIMPLEST SCENARIO

SIMPLEST SCENARIO IS……THE CASE WHEN ALL THESE STEPS DOES

NOT REQUIRE TOO MUCH EFFORT

«2 DAYS FOR RELEASE»

20

SIMPLEST SCENARIO

? ? ?

!release

/trunk

1 2 3 ? ? ?1.0 1.1 1.2

21

MORE COMPLEX EXAMPLEExtending the scope

22

IMAGINE …

YOU NEED TO STABILIZE YOUR RELEASE

and

PROVIDE SIMULTANEOUS DEVELOPMENT OF ANOTHER APPLICATION VERSION

23

?

BRANCHING FOR RELEASE

? ? ?

!release

/trunk

1 2 3

? ? ?1.0 1.1 1.2

!merge

? ? ?2.0 2.1

/1.x

2.32.2

24

BRANCHING FOR RELEASE

DID YOU NOTICE?

INCONSISTENCY IN VERSIONS NUMBERING!

IT MAKES SENSE TO SEPARATE DEVELOPMENT IN TRUNK AND RELEASE STABILIZATION

25

BRANCHING FOR RELEASE

? ? ?

/trunk

1 2 3

? ? ?1.0 1.1 1.2

? ? ?4 5

/1.x

6

? ?2.0 2.1

? ?7 8

/2.x

26

EXAMPLE EVEN MORE COMPLEXParallel branching

27

BRANCHING FOR RELEASE

YOU WILL NEED TO BE ABLE TO GO TO THE RELEASE STABILIZATION ANYTIME

and

DO NOT INTERRUPT ANY OTHER DEVELOPMENT OR RELEASE STABILIZATION

28

/1.x

/2.x

BRANCHING FOR RELEASE

? ? ?

/trunk

1 2 3

? ? ?1.0 1.1 1.2

? ? ?4 5 6

? ?2.0 2.1

? ?1.3 2.2

0.1 0.2 0.3 0.4 0.5 0.6

29

BRANCH TYPES

It’s time to think about branch types!

?

30

BRANCH TYPES

? ? ?

/trunk

1 2 3

? ? ?1.0 1.1 1.2

? ? ?4 5 6

? ?2.0 2.1

? ?1.3 2.2

/1.x

/2.xrelease branch

release branch

no type(it’s just trunk)

x.x

x.1 x.2 x.3 x.4 x.5 x.6 x.7 x.8

31

EXAMPLE OF THE CASE, WHEN BRANCHES BEGIN TO GROW BY THEMSELVES.

32

BRANCH TYPES

? ? ?

/trunk

1 2 3

? ? ?1.0 1.1 1.2

? ? ?4 5 6

? ?2.0 2.1

? ?1.3 2.2

/1.x

/2.x

x.1 x.2 x.3 x.4 x.5 x.6 x.7 x.8

incompatible changes

cannot merge

33

BRANCH TYPES

Incompatible changes means:changes cannot be easily merged to

the parent branchExample:

deep refactoring (files hierarchy changes)

serious architecture/application structure modification

rewriting application or its part from scratch

34

BRANCH TYPES

? ? ?

/trunk

1 2 3

? ? ?1.0 1.1 1.2

?4

? ?2.0 2.1

?1.3

/1.x

/2.x

x.1 x.2 x.3 x.4 x.5

/?

cannot merge

/1.x.x

0.x.x

release branch

release branch

support branch

0.x.1 0.x.2 0.x.3 0.x.4 0.x.5

/0.1.x

/0.2.x

0.1.0 0.1.1 0.1.2

0.2.0 0.2.1

35

BRANCH TYPES

/trunk

/0.1.x

/0.2.x

/1.x.x

/0.3.x

/1.0.x

support branch

release branch

36

SUPPORT VS RELEASE BRANCH

Does not allow merge with parent branch

Exists forever

Child branches are allowed

Cannot have another support branch as child

Deprecates merging with child branch

Allows merge with parent branch

Exists only until stable version is released

Child branches are not allowed

Support branch Release branch

37

x.5x.3

BRANCH TYPES

/trunk

?1x.1

x.0 x.2 x.4

x.7 x.9

x.11

x.6 x.8

x.10experimental branch

38

EXPERIMENTAL VS RELEASE BRANCH

Does not allow child branches

Uses strict branch name. Example: 1.0.x

Uses own scope of builds numbering

Recommended merging approach: after each build/release

Allows any number of child branches

Name is not restricted at all. Example: new_eng_test

Shares scope of builds numbering between all relative branches

No recommended merging approach

Release branch Experimental branch

39

CODEBASE INHERITANCE

/trunk

/0.1.x

/1.x.x

/0.2.x

/2.x.x

0.x.x

latest development

40

CODEBASE INHERITANCE

Latest development should reside in trunk

41

CODEBASE INHERITANCE

/trunk

/1.x.x

/3.x.x

/2.x.x

4.x.x3.x.x2.x.x1.x.x

42

TYPES OF BUILDS

releases

alpha release

(AR)

beta release

(BR)

release candidate

(RC)stable (ST)

builds

pre-alpha (PA) alpha (A) beta (B)

43

SCM IN ACTION

/1.x.x

/1.0.x

1.x.x 2.x.x

1.x.0

1.x.1

1.x.2

1.x.3

1.x.4

2.x.0

2.x.1

1.x.5 2.x.2

/trunk

PA

A

Bbuilds

AR

BR

RC

ST

releases

1.0.0

1.0.1

1.0.2 1.0.3

1.0.4

44

SCRUM AND SCM

1.x.0 1.x.1 1.x.2

/trunk

1.x.3 1.0.0 1.0.1

sprint backlog

user stories

/1.0.x

demoPA/A AR/BR

45

SOURCE CODE REPOSITORY DIRECTORIES HIERARCHY

46

DIRECTORIES HIERARCHYPROJECT

47

DIRECTORIES HIERARCHYTAGS

48

DIRECTORIES HIERARCHYSUPPORT BRANCHES

trunkPA

A

B

/tags/builds

AR

BR

RC

ST

/tags/releases

1.x.0

1.x.1

1.x.2

1.x.3

2.x.1

1.x.5

1.x.4

2.x.2

2.x.0

/branches/maintenance/versions/1.x.x

/branches/releases/1.0.x

1.0.1

1.0.2 1.0.3

1.0.0

1.0.4

1 12 39 52 73 79 93 112 126 139 155 170 193 201 215 230140

1.x.x 2.x.x

Номера ревизий

49

Afterword

AFTERWORD50

51

Thank you for attention!

52

USEFUL LINKS

1. http://www.infoq.com/articles/agile-version-control - agile version control

2. 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 control

4. http://www.versioncontrolblog.com/ - another great blog about version control

5. http://better-scm.berlios.de/comparison/comparison.html - VCS comparison table

6. http://www.cmcrossroads.com/ - biggest resource about SCM

7. http://www.infoq.com/news/2009/03/Continuous-Deployment - about continuous deployment