Tim Segraves

While these two topics are often discussed in the same context, they are in many ways, opposing ideas. Continuous Delivery requires a path to production for any code that is ready to be released but Continuous Integration says you should be integrating all of your latest code together multiple times per day. This makes releasing a certain feature that is ready difficult because it has been integrated with other code that may not be ready for prime-time.

In this post I’ll talk through a couple of techniques to find the balance of continually integrating your latest code while also being able to do on-demand releases of any work that is ready.

Branch By Feature

While this has typically been frowned upon by the CI crowd, there are some benefits to this approach. The perceived negatives of this approach are:

• * It promotes long running feature branches where the code isn’t integrated with other work until it is pushed into the trunk.
• * Branching has a lot of overhead.
• * It causes developers to work in a silo where they are not in touch with the rest of the team.

While these can be negatives, there are some techniques that can be applied to get around these. GitHub branches by feature successfully by pulling down latest from master for any feature branch that runs longer than a few days and utilizing pull requests to move code between branches. They also are able to run their test suite on any branch. A few things that can make branching by feature work better:

• * Keep your work items small. Small work items or stories can be completed in a couple days or less which should immediately be merged into master and released once they are completed and have passed all automated tests. Feature toggles may be required in order to hide incomplete features.
• * Merging down from master allows you to keep your branch in sync with anything that’s been released to production.

Integrated Feature Branches

I first read about this from a post from Adam Dymitruk as I was investigating a similar solution for my company. It basically starts out like the above flow from GitHub but adds in a CI branch.  Each feature is developed in isolation but regular checkins and merges are made to an integration branch where tests are run and you verify that all of the in-progress code plays nice.

The key to making this work with CD is to only merge up to the CI branch and never merge down.  By merging down you lose the ability to deploy your code in isolation so this should be avoided.

In the event you want to use some code someone has written in another branch you can cherry pick it from that branch directly without talking to the integration branch.  Some other benefits of this approach are:

• * It keeps the ability to release code to production in isolation.
• * Code is still integrated constantly to ensure developers aren’t breaking each other’s code and not knowing for days or weeks.
• * It also allows for more rapid development since you are able to focus solely on your code in isolation.
• * When using Git on another DVCS you can still collaborate with other developers on a single feature branch.

Tooling

Obviously tooling becomes very important for branching by feature to work.  Using something old school like SVN or TFS will have obvious issues with all of the branching and merging but in theory it would still work.  More modern systems like Git or Mercurial makes this much easier among other things.

Now go forth and branch, integrate, and ship your code!

I officially opened up the site I’ve been working on this morning to new users.  You can signup for free at www.twistertracker.com and start tracking severe storms and tornadoes as they happen.