Continuous Delivery Workflow

A common objection people raise when we’re talking about testing and feature branches is that it’s not “pure” CI.

And that’s true. You don’t have everyone’s changes stewing together on one code line. But that’s kind of the point. Using a single code line tends to make that code line rather unstable. But "pure" CI does carry the advantage of knowing right away if your changes play nicely with your teammates' changes.

So how do we get the best of both worlds? How do we get feedback about integration without creating chaos on a critical branch?

Use a shared integration branch

An option that is close to "pure" CI is to include an integration branch in your team’s workflow – a concept you'll find in the Gitflow branching model, where this branch is called "develop". When you’ve completed implementation on your feature branch and you’ve got a clean CI run there, merge up to the integration branch.

The fact that Martin Fowler, Jez Humble, and other CI/CD enthusiasts came out against feature branching when it first became popular a few years ago left a strong impression on the software community – developer blog posts and posts to StackOverflow on the subject abound. CI purists are unlikely to be swayed by any idea I've offered here.

But that's ok. For the rest of us – we CI pragmatists – feature branching offers a way to keep master clean, without degrading the rigor of our testing practices.