Master Code Line is a scaleable strategy for using software control. It scales very well from a team size of one to a team of thousands. As the size of the development team working on a code base increases it becomes ever more important the whole team uses the same strategy to avoid some very serious and expensive mistakes: “the use or misuse of branching and merging can make or break a parallel software development project” .
Perhaps the best example I can give here is from my current company. When I first started working there I was shocked to discover everybody was working off the main trunk (main line). Lost code was commonplace as they were working to a ‘s/he who submits last wins’ process. The one product that did use branches had two: one for each flavour of the product. Code was never propagated, merges never performed and changes made to one branch had to be manually applied to the other. Software quality could be measured on a scale of negative numbers. Very large negative numbers!
I made it my mission to change that and introduced them to the Master Code Line Strategy…
I first came across the Master Code Line strategy when I joined Symbian Software. We have somewhere in the region of a thousand developers using it on a code base of about 6 million lines of code. It’s very easy to use, scales well and is tool agnostic. I’ve used it on Perforce, SVN and Git.
The diagram I’ve drawn above shows the evolution of a master code line codebase over time. You will see that no changes are made to the Master branch (often referred to as the Trunk or Main Line). All development work is carried out on the top half of the diagram and releases are created and maintained on the lower half. One of the fundamental concepts is that as the code works it’s way down from the top of the diagram to the bottom, the quality increases. The exception to this being the Hotfix branch and we will discuss that later I this post.
Master, Trunk or Main Branch
The Master Code Line (MCL) is the main trunk for the software. This is the only code line from which releases are made and no changes are permitted on this branch under any circumstances. Ever! This ensures the MCL is always at release or product quality. Ideally, the code on the MCL will be used for overnight builds and testing to verify its quality level.
Build breaks and test failures are not allowed on Master! When they occur they must be resolved immediately and, depending on the severity, may result in a root cause investigation.
Develop Branch
The Develop branch is one step removed from Master. Its primary role is to integrate changes from feature work and defect fixes and to allow those changes to be tested against the MCL without touching the MCL. The secondary purpose of this branch is to catch build breaks and test failures before they reach the MCL. Whilst this branch can break, it is strongly discouraged. As with the MCL, no direct changes are allowed on this branch.
New Development and Defect Fixes
The red area at the top of the diagram if the zone where new feature branches and defect (bug) fix branches live. They are created from the Develop branch and are entirely under the control of the developers. These branches are allowed to break but must be code complete, working and all tests passing prior to propagating changes to the Develop branch.
Release Branches
Release branches are taken directly from the Master Code Line. Their purpose is to create a quiet branch that can be used for product hardening prior to making a release. Doing so allows new features and defect fixes that are scheduled for the next release to be propagated to Master without contaminating the code on the release branch.
When the release branch is deemed ready for release, a tag is created to identify the exact commit the release will be built from. Point releases of the same major and minor version of the code are also taken from this release branch, new tags being created as necessary.
Hotfix Branches
Hotfix branches are created directly from the release branch they relate to. They provide a mechanism for defect fixes to be made for a particular release without the need to propagate any new features to the code line.
Changes made as a result of a hot fix can (and in most cases should) be propagated back to the Master and Develop branches. This is illustrated in the diagram above with the orange square being changed into an orange circle and making it’s way up the branches to the developers.
Propagating Changes
Using branches within any version control system means changes on those branches need to be propagated to other branches. This requires being able to merge changes from one branch to another. With some systems, such as Perforce and SVN, merging requires some form of branch history under normal circumstances. Other systems, such as Git are less strict.
Whichever system you use, one fact remains: it’s vitally important to be aware of which direction you are merging, either towards or away from the MCL.
Note: The remainder of this section will be Git specific.
Pull Request
A Pull Request, commonly referred to as a PR, is used to invoke a merge towards the main line or a release branch. i.e. when you wish to propagate your changes to a controlled branch. This type of merge will typically involve some form of code review and/or other quality checks, all of which need to pass before the changes will be merged.
Merge
A merge should only be used when propagating changes away from the main line. This type of merge is often referred to as a ‘catch-up’ as it is usually used to catch a feature branch up to the develop branch.
Tip: one way to avoid merge conflicts is to frequently catch up a feature branch to the develop branch to reduce the likelihood of multiple developers changing the same files.
Golden Rules of MCL Version Control…
- Commit frequently — it can be a lifesaver
- Never work directly on the Master or Develop branches
- Always use a Pull Request (PR) when propagating towards Master or a Release branch (Git specific)
- Keep your repo tidy — close branches after a PR has been merged if no longer required
- Adopt a sensible naming convention e.g.
feature/gavin/<feature_name>
bug/gavin/<bug_name>
release/<major>.<minor>.x-<release_code_name> - Catch-up your branches to Develop often and always before creating a PR.
- Merge conflicts should be resolved with all affected parties
Conclusion
Master Code Line can feel like overkill at first but it works extremely well and is designed to catch errors before they make it into the product. Version control, by it’s very nature requires discipline on the part of the whole team to be effective and Master Code Line encourages this with a simple to use and scaleable framework.
There are many different strategies for version control (see References below) but I have found Master Code Line to be the most versatile and robust. At Symbian Software we had around 1,000 developers using this strategy with Perforce. The code churn in that environment was enormous and whilst build breaks did happen they were mostly down to developers trying to take short cuts, going off-piste and not sticking to process.
List of Images
Figure 1. THORN, 2020 Master Code Line at Work
