“Continuous Delivery is the logical evolution of Agile” - this statement was written by Kurt Bittner in 2013 in a report of Forrester. Back in those days Continuous Delivery was not yet as far in the hype cycle as today. In the Application Development hype cycle that Gartner presented in 2015, Continuous Delivery was on the rise and nowadays it is in every year plan of any IT-related company. But what exactly is Continuous Delivery, and what does Continuous Delivery 3.0 add to this concept and what does it have in common with Digital Disruption. In this article you will find answers to these questions and learn why it is important to look beyond the hype cycle.
Continuous Delivery is the fulfillment of the Agile promise. With over 95% of companies practicing Agile, it is a logical and required step for most companies to look further. Agile brought us the benefits of being able to produce high-quality software produced in a matter of weeks. But the next challenge, delivering the software and delivering business value to the customers, proved to be a whole different ball game.
This is where Continuous Delivery comes in. Continuous delivery is a software engineering approach in which teams produce software in short cycles, ensuring that the software can be released reliably at any time. Its objective is to build, test, and release software faster and more frequently. Ideally this means that all functionality is planned, realized and released with the same repeatable process, called a pipeline. Quality gates (like unit tests, continuous builds, acceptance tests, and metrics) ensure that the functionality and quality is guaranteed. If something is not right, the pipeline is stopped so that the error can be fixed. Therefore, metrics should be in place to understand, trace and pinpoint the error to make sure this does not happen again. Every piece of software, whether it is a bug fix, new feature or a change request, is treated in this same manner. This sounds perfect for new projects and new software, but how does this work within existing scenarios and within organizations that have already been building software for many years? Before I dive in to this, I want to talk a bit about digital disruption.
Xebia DevOps
