Version Control

Every time the code changes, it traces back to some task being done. Think about it; Who’s feeding the process? How are tasks being created, prioritized and executed?

When a code change cannot be tied to a specific task, it’s likely something that has bypassed the normal chain of command. Somebody is working outside protocol.

Make all code changes part of an overall plan - simply pair commits with tasks. Besides generating valuable traces that can later be used in an audit or documentation of your trail, it also enables you to track the pace of the team and maintain a burn-down chart.

The release train branching strategy is similar to what is sometimes referred to as late branching or trunk based development. Essentially it implies that in your entire branch tree there is only one branch that is meant to be long-lived.

Consequently, there is only one way you can contribute to a product and have your code released, and that is to deliver your code to the mainline.

In a release train strategy, the mainline is on it’s way to production all the time, and therefore anything that isn’t meant for production as soon as possible, shouldn’t be delivered to the mainline.

Versioning schemes are a powerful tool.

They give you a quick and accurate reference to when, where and by whom something was made, what it’s compatible with, etc.
It is the name of your release, the identifier of your component, the passport of your product.

Implement a well-defined versioning scheme for your components and releases.

Distributed version control systems are a faster, modern alternative with a healthy community. Due to its distributed nature, switching to git opens up many doors to automation. e.g.: It allows for automation tools to work in a local repository without jeopardizing the mainline.

Keep your project’s history clean and understandable. Make it easier to find specific commits and for others to review. When finishing up work in your short-lived branches, clean up your local commit history before merging back into the integration branch.

To integrate means to merge your code on to the same branch as the one your colleagues are working on. So obviously if your code breaks something you are potentially jeopardizing the work space - and pace - of your team mates as well.
To have a pristine integration branch means that it is buildable at all times.

Code should be verified through some kind of toll-gate criteria, before it’s accepted on to the integration branch. Anything that doesn’t meet the toll-gate criteria is rejected and will not enter the mainline. It is simply impossible for a developer to break the build.