Hi again, the topic is again version control branching strategies and release management.

A few months ago, I wrote the “rules” of our release management procedure (see part1). WOW, this 2nd post takes as much time as to write a new release of the code. I excuse myself for the delay, as I live in Greece and summer is so great that no one can resist on sunny beaches and colourful sea.

OK, it’s time for the simple release management example. As at most times, an image is better than thousands of words. This is not always true, try to find an image to explain wise. I am sure you cannot 🙂 So many books have written, but still we cannot understand/define wise. So sad for human kind…. Let’s go to something more simple like release management. So, check the following image:

Release Candidate scenario of application PName:

1. Development is done on TRUNC and all developers work there. Application is at stable release 1_9. and after a lot changes want to go to release 2_0. The underscore is used instead of dot to comply with most version control software variants (CVS is not accept the dot in tags)
2. When developer finish his unit testing and as many integration tests he could accomplish, then decide that application is ready for integration and acceptance tests and so he creates a Tag on trunk with name ‘RC_2_0_PName_BASE’. This the release candidate timestamp on TRUNK, as tags are timestamps.
3. Release Candidate 2_0 is branched using name ‘BR_RC2_0_PName’.
4. During Integration Test an issue is raised. It is fixed on branch and then tagged as BT_RC2_0–1_PName.
5. Developer decide that is better to merge the changes back to TRUNC, while the rest of the development team continues to work towards to RC3_0. So, two things must be done:
1. Commits paused for AppName application (using a loud announcement like “Go for coffee I must merge to trunk”).
2. He tags TRUNK with RC2_0–1_PName_PMB.
6. Developer merges the branch to TRUNC.
7. Developer do the required commits (if any) to have a valid application on TRUNC and create a new tag on TRUNC named RC2_0–1_PName_AMB. Developer announces “Go back to work” and unpauses commits on PName application.
8. During Acceptance Test another issue is raised. Code needs a few modifications, after a few commits, issue is resolved and committed on branch. Then branch is tagged as BT_RC2_0–2_PName. No merge to trunk here (developer decides here as he is the release manager in our case :))
9. During Acceptance Test another issue is raised. Code needs a few modifications, after a few commits, issue is resolved and committed on branch. Then branch is tagged as BT_RC2_0–3_PName.
10. Acceptance Tests are completed with the modified code unattached. Now release “2_0” is ready. Developer create a tag BT_R2_0_PName on branch, which is exactly the same code as BT_RC2_0–3_PName.
11. Now, developer must merge the code to TRUNK. First pause the commits on the trunk and then creates a tag named R2_0_PName_PMB.
12. Developer merge the changes to trunk.
13. Then do additional required commits and create another tag named R2_0_PName_AMB and afterwards unpause the commits on TRUNK.
14. While application (release 2_0) is running on production another issue is raised that needs a quick fix. Problem is fixed on branch and a tag is created on branch with name BT_RC2_0_1_PName.
15. Additionally the quick fix is also tagged as release with tag name BT_R2_0_1_PName.
16. Developer must (in most cases) merge the changes back to TRUNC while the rest of the development continues to work towards RC3_0. So, he pause the commits on application and tags TRUNK with R2_0_1_PName_PMB.
17. Developer merge the changes from branch to trunk.
18. Developer do the required commits to have a valid application on TRUNC and create a new tag on TRUNC named R2_0_1_PName_AMB.
19. Development on TRUNK is still towards to RC3_0 and work is never ends…

The above rules/steps are referred to only one application, but are the same for all applications.

Please read again the first post of this series to understand the rules. I know that you will need explanations on the image, so please ask. A few important explanations:

• Branch tags will always start with ‘BT_’
• Release candidate prefix is ‘RC_’
• Release prefix is ‘R_’
• Release numbers are separated with underscore (e.g. 2_0)
• Tags that are not releases but are related to a release candidate are using 2 dashes ‘–” (e.g. 2_0–1)

Using this procedure we can go back to any release of PName that we want (using the branch tags) and continue the branch with a quick fix, or even create a new branch of branch.

I know that there are better and more elegant procedures, but this is just the procedure that we follow and works in our small development team. It is simple, without any additional tools, but needs strong communication between developers, an issue tracker (we use mantisbt) and require developers always follow the rules. Also, you many need a wiki (we use MediaWiki) to record all the tags for each application. The release notes are recorded into the issue tracker.

Without rules and release management procedure, even a small application can be very complex after a few production releases. Always define rules and be sure that are acceptable by all developers. If there is a leak in the defined procedure, then the developers will find it and apply it for sure. As now the developers are the users of the product (product = release management procedure) and users are always unpredictable.

Hope it helps,
Adrianos Dadis
—
Democracy Requires Free Software.