Scaling with branch review

You can improve the scalability of a centralized continuous delivery process by adding code review. This gives you some of the simplicity of the centralized process, with some of the scalability of the distributed or continuous release process.

We like a review process where every contribution aimed at the master branch goes into a temporary branch, where it can be tested and reviewed by automated tests and by other developers.

Adding change review to a centralized continuous delivery process increases the quality and stability of the target branch because it:

• Gives you a convenient place to put "pre-commit" automated tests, so that your automated test system can reject changes that don't pass before they are merged with the mainline.
• Saves reviewer time, because reviewers do not look at code until it at least passes the automated tests.
• Helps you bring in new contributors through reviews and comments.
• Allows you to have a much larger number of contributors without breaking the build.
• Helps you build your suite of automated tests, because your reviewers can ask contributors for automated tests.

Merge request implementation

In one implementation of this workflow, a contributor submits a "merge request" or "pull request." Automated test systems and reviewers can pull the change and test it before agreeing to merge it.

Temporary branch implementation

In systems like Gerrit, contributed changes automatically go into a temporary branch. The built-in workflow will run tests, collect reviews, merge the change, and throw away the branch. This process tends to be more centralized and unified, because contributors start from the shared branch and they do not have to maintain their own branch or fork.

Assembla implements both workflows, merge request and temporary branch.

Pre-flight testing and review

If you do not want to make a lot of branches, or if you have a code repository that does not support lightweight branches, you can do pre-flight testing and review by having a second system that looks at changes before they get committed to the shared repository. This is called "pre-flight" testing. For example, Electric Cloud makes a system which can overlay pre-flight testing on various code repositories.

Distributed starts to look like centralized

Just as a centralized continuous delivery process can take on elements of distributed processes, so too can a distributed process evolve to resemble centralized processes.

In a distributed continuous delivery process there is an incentive to release frequent, small changes. Why? Because small changes are easier to debug. If you discover a problem, you only have to look through a small amount of changed code to find it and fix it. When problems show up in a large release, they are harder to fix and they create more stress.

Because of this incentive, distributed continuous delivery teams often move over time to frequent, small releases, with a mainline that is constantly updated. This mainline version will look similar to a single centralized version.