GitHub Workflow vs Mainline Development

June 22, 2013

As mentioned in an earlier post, Continuous Delivery means:

To achieve the above we need extensive automation of all possible stages of the delivery process, using something called as Deployment Pipeline.

The image below should explain the workflow of continuous delivery: Continuous Delivery Workflow

To achieve the above, the following are mandatory:

This blog post is a comparison of GitHub style workflow with Mainline development and how the Review process in the GitHub style workflow affects Continuous Delivery.

GitHub Workflow

The following is the normal GitHub workflow:

Github Workflow

The above workflow ensures the following:

But inhibits Continuous Delivery because:

Does that mean that code review is an anti-pattern for Continuous Delivery? Not Really. Code review is good. Its so good that we should be doing it continuously .The following can help you to achieve that:

The above is aligned with the principle Build Quality In, which emphasises that “Every team member is responsible for Quality”.

Feature Toggles

One reason for using Branches is to avoid dependencies on work-in-progress items - when there are expedites, for example. But this problem can also be solved without Branches using what is called Feature Toggling.

We’ll go one step further at this point and say that that Feature Toggling is a much better to solve the problem of dependencies - because the toggles can also be used in production - for testing new features with a smaller audience of users - and rolling out the features to a larger audience once the initial feedback has been processed.

Final Note

The GitHub style workflow makes perfect sense for Open Source projects - to bring in some amount of rigor to the bazaar. But in a more controlled environment, relying on interdependence within the team itself for code reviews (with pair programming and TDD) makes more sense.