Speed, Discipline, Quality — Not a Paradox?

Continuous Delivery is making sure that the code is always ready for deployment. This allows teams to deliver at business cadence. The engineering team is responsible for making sure that the software is deployable at any point of time.

We believe that Continuous Delivery is for everyone and is about simple techniques that can help us ship better software.

Continuous Delivery achieves it by extending Continuous Integration by confirming that every commit is deployable.

Continuous Integration requires every team member committing to trunk [a.k.a master or mainline], to avoid the time spent on merging and resolving conflicts because of long-living branches.

Use Feature Toggles to turn off the features:

  • Under development
  • Waiting for confirmation from business stakeholders

Then extend Continuous Integration for deployments, to make deployments a low risk activity.

This is where the Deployment Pipeline comes into picture, with different stages deployed either manually or automatically.

Courtesy: http://blog.crisp.se/2013/02/05/yassalsundman/continuous-delivery-vs-continuous-deployment

So what does Continuous Delivery give us?

  • High quality — every commit gives you feedback within minutes (ideally :) ) about any regression issues
  • Faster time to market — with complete automation, the time for each commit reaching production can be fast
  • Low Risk Releases — With automated testing and deployment, releases are more predictable and reliable and every deployment becomes less risky.

Yes, these need discipline which is achievable with enough investment — for setting up the pipeline and future maintenance whenever required.

So what are you waiting for? Switch to Mainline Development and Feature Toggles.

More about Continuous Integration:

Continuous Integration on a Dollar a Day

The Death of Continuous Integration

Merge Hells? Feature Toggles to the Rescue