The best way to explain the need for these best practices is by putting together an example of a real world project scenario and show how exactly will these best practices fit into the “bigger picture”. Also, a lot of readers have told me that the sections on Branching and Merging and Change Propagation will require examples for better explanation. Listening to the readers is a Good Thing so I have put together a particular project scenario and then create a series of events to show how the best practices, if followed, would help is making operations smoother.
Consider a software project where version 1.0 has just been put into production and everyone is done celebrating. The next step is to start working on the new features of the subsequent release. Also, the users of the system have started to use it full-time and bug reports of various levels have started to come in.
Before jumping into new enhancements or bug fixes, the best practices for Branching and Merging should be followed. Few of the important practices are Tag each release and Create a branch after each release. These practices will effectively established two “development environments”, one for regular enhancements and the other for bug fixes and minor enhancements on the last release.
Let us assume that the release was tagged as
release_1_0
Then the branch was created with the branch name
release_1_0_patches
Now, we are ready for business. Let us examine the bug fixes and enhancements track. Assume that there are three bugs of which two are of a high priority that should be fixed right away (possibly within a week) and the third can be delivered after some time (say after 4 weeks). In the middle of this schedule there is a regular release scheduled in three weeks. Considering that we have a busy month ahead, let us see how exactly we can use the Best practices to ease the days ahead.
The timeline for the various release in the next month looks like this.
Fix Enhancement Fix
Today Release 1 Release Release 2
|_______|______________|_________|
Time -->
We have two teams, one working on the bug fix branch and another team working on the features for the next release on the main trunk. These teams must make sure that they start out with the right version in their sandbox.
The bug fix team will check out using the command line
cvs checkout -R -r release_1_0_patches {project name}
The team that is working on the next release will use the command line
cvs checkout -R {project name}
As soon as the bug fix team completes the two top priority bugs, they will update, verify a successful build and commit their changes to the bug fix branch using the command line
cvs update -R -r release_1_0_patches {module name}
The team should perform a build at this point to verify that the update did not break any code on the branch. Once the build is successful, the branch should be committed back into the repository.
cvs commit -R -r release_1_0_patches {module name}
Build Early and Build Often : On a daily basis, each developer will check in code to CVS and to ensure sanity of code, daily builds on the bug fixed branch will be undertaken by checking out from CVS on a clean environment and completely rebuilt. These daily builds can be tagged in CVS using the following naming convention
build_1_1_yyyymmdd : for the branch
build_2_0_yyyymmdd : for the trunk
The regular process of build-test-fix is followed to make a version ready for delivery. The tag will help developers checkout a working copy of the latest build as and when necessary.
When the source code is released to the outside world, two practices have to be followed.
Tag each release : This ensures that the bug fix release is tagged correctly and so can be traced out at a later point in time if necessary.
Merge branch with the trunk after release : This ensures that the bug fix is merged back into the main trunk ensuring that all future releases is a truly cumulative delivery.