“It works on my machine” – anonymous
Branching is a powerful tool in managing development and releases. There are many different styles of branching. One debate is what work will happen on the trunk, and what will happen on the branch. Coming to branching model or the branching strategy , one that worked for your project may not be work for my project. Branching is also dependent on the type of the tool being used – Clear Case, CVS, SVN, TFS, Git, Bamboo, etc. Also it changes based on team – is at co-located or distributed, is it service based delivery, or product based delivery, multiple organizations involved in developing and integrating the code before release into the market, size of the source code, parallel/concurrent development, etc. Many more such factors influence the branching strategy.
Few of the strategies is given below and for ease of representation, few terms have been generalized as much as possible. GIT and Bamboo becoming more popular and newer way of development with git-svn, tfs-git combinations, branching and merging strategy could be combination of some of these and with git at developer and tfs at portfolio, best practices across the tools are also merged and branched.
One common across the models given below is Development branch is used to carry out day-to-day activities and Main branch is used to create various branches to support parallel development and also to keep these branches in sync using merging. Main branch supposed to be stable code.
Each of this has multiple pros and cons, not dealt here for reasons explained above.
Branching Model for Product support by Customer. Different product support for different customers
Multiple applications, Multi Vendor and Scrum Team based
Branching by Development Teams / Scrum Teams
Release Based Branch
Below model enables concurrent development for releases, a stable MAIN branch for testing and a release branch for any ship blocking bug fixes.
Multiple development areas are supported by creating additional development branches from MAIN. These are peers to each other and children of MAIN.
Additional releases are supported by creating additional release branches for each product release. Each release branch is a child of MAIN and a peer to each other (e.g. release2.0 branch is peer to release3.0 and both are children of MAIN).
Once the release branch is created MAIN and the development branches can start taking changes approved for the next product release.
Release based branching but for independent development team and independent support team for change management
Feature Based Branch supported for Integration of Features
Branching by Scrum Teams, by Release, by Sprint
- Branching for test / QA : No separate branches per test environment is needed. Rather deploying from a development branch to the QA . If you look at the branching structure, the branches furthest from main are more and more focused on features, while the branches closest to main are focused on integration. One can build and deploy the code from a feature branch for QA testing or can build and deploy code from the Dev branch for testing. QA stabilization prior to release is needed
- Integrations : The primary cost of a branch is in the time and potential for mistakes to be made during integrations. The general guidance is keep branching to a minimum. Merge (FI) from parent to child frequently. Ideally do not let a branch get more than 1-2 days out of sync with the parent. Merge (RI) frequently from child to parent based on build and automated test results.
- Cherry Pick : Cherry picking is the process of selectively choosing which files/change sets to branch/merge. Although, there are situations where cherry picking could be necessary, such as when we need to fast-track a critical fix from one branch into another. But as the complexity of a project increases, cherry picking is more likely to cause problems such as fixed bugs that appear again in new builds or broken builds due to incorrect file versions. Also, cherry picked changeset can fall in the middle of a future merge range resulting in remerge of that changeset. This can result in merge conflicts.
- Commit and Build in Dev branch : A successful build only indicates that sources are syntactically correct and generated no build-time (i.e. compile, link, or packaging) errors. Before committing more people, hardware and time to testing this build it’s important to determine if build is “testable.”. Pull request in Bamboo, git and gates check in TFS are helpful for the reviews and successful check in with no errors
- Environment :Development
- Branch: DEV
- Note: Usually the DEVELOPMENT environment will reflect the latest good build from one of the DEV branch.
- Environment : UAT
- Branch: Usually MAIN, sometimes PRODUCTION when previewing a software release that needs to pass UAT
- Notes: In most cases the UAT environment will be running a high quality build from the MAIN line
- Environment: Staging/Pre-Production
- Branch: PRODUCTION
- Notes: Pre-Production will almost always have a build from the PRODUCTION line
- Environment: Production
- Branch: PRODUCTION
- Notes: PRODUCTION always contains a build from the PRODUCTION line
Why bother with branching?
Branching allows teams of developers to easily collaborate inside of one central code base. When a developer creates a branch, the version control system creates a copy of the code base at that point in time. Changes to the branch don’t affect other developers on the team. This is a good thing, obviously, because features under development can create instability, which would be highly disruptive if all work was happening on the main code line. But branches need not live in solitary confinement. Developers can easily pull down changes from other developers to collaborate on features and ensure their private branch doesn’t diverge too far from the master.