Continuous delivery

ThoughtWorks’s Vladimir Sneblic today held the excellent Continuous Delivery course at QCon 2013 together with his colleague. Expanding on the well-known must read from Jez Humble, the tutorial included anectodal stories, case examples and professional materials.

In a nutshell, Continuous Delivery proposes to improve the painful – at least in most larger companies I know of – process of software delivery from development to operations by increasing delivery / deployment frequency. There are multiple reasons to do this. Massively increasing delivery frequency:

  • decreases the increment size, reducing the risk resulting from the scope of the change,
  • forces to focus on the delivery process and drives automation efforts,
  • uncovers the necessity to cooperate especially between Dev and Ops,
  • shows the urgency to improve the structural deficiency in Ops,
  • and ultimately reminds of the importance of Ops in the context of software development.

However, implementing Continuous Delivery is a major change effort. The following is a list of things to implement, supposing that an agile software development is already in place:

  • Continuous integration
  • Trunc is always production ready
  • Automated testing
  • DB migration tools
  • Agile infrastructure
  • Comprehensive confugration management (Everything is in version control)
  • DevOps

In larger corporations this results in a major organizational transformation to be pitched at the level of the corporate CIO.

About Grischa Ekart

Follow me on Twitter: @gekart. I am a trainer and consultant for AWS, Docker, Kubernetes, Machine Learning and all things DevOps.
This entry was posted in Continuous delivery. Bookmark the permalink.