The right branching strategy makes it easier to deliver the right code, re-create past releases, and if necessary, roll back to a previous release. Adopting the right SCM branching model facilitates rapid development, increases overall product quality and process efficiency, reduces the incidence of software failures, and improves organizational performance.
Selecting the appropriate branching model lets the release engineer serve several masters that some times have conflicting interests or priorities: the development group, the testing group, and the support group — which represents the product’s end
users.
Here are some of the common branching models:
1. Branch-by-release Model: One of the most common branching strategies is to align branches with product releases. A branch holds all the software development assets for a single release. Occasionally, updates need to be merged from one release to another, but they usually never merge. Branches will be discontinued when a release is retired.
2. Branch per Promotion: Another very common approach is to align branches with software asset promotion levels. A specific development version is branched off into a Test branch, at which all the integration and system testing is performed. When you complete testing, the software development assets are branched into the Production branch and ultimately deployed.
3. Branch per Task: To avoid overlapping tasks (or activities) and a loss in productivity, you can isolated them on a separate branch. Keep in mind that these are short-term branches that should be merged as soon as the task is completed, for otherwise the merging effort required may exceed the productivity benefits of creating them in the first place.
4. Branch per Component: You could align each branch with the system architecture. In this strategy, you branch off individual components (or subsystems). Then each team developing a component decides when to merge their code back into the development line that serves as the integration branch. This strategy can work well if system architecture is in place and the individual components have well-defined interfaces. The fact that you develop components on branches enables more fine-grained control over software development assets.
5. Branch per Technology: Another branching strategy aligned with the system architecture. In this case the branches are aligned to technology platforms. Common code is managed on a separate branch. Due to the unique nature of the software development assets managed on the branches, they probably never merge.
A few common points from these strategies:
* All branches have a clearly defined lifecycle. They either live forever, or they are eventually killed off.
* All branches are created with the intention of eventually merging, somewhere. A branch without a merge is pointless.
* As we add branches, our development model gets complicated.
Recent Comments