- 1.1 Introduction: What Is Continuous Delivery?
- 1.2 Why Software Releases are So Complicated
- 1.3 Values of Continuous Delivery
- 1.4 Benefits of Continuous Delivery
- 1.5 Generations and Structure of a Continuous Delivery Pipeline
- 1.6 Conclusion
This chapter is from the book
This chapter is from the book
This chapter is from the book
1.2 Why Software Releases are So Complicated
Software releases are a challenge—very likely every IT department has already worked during a weekend to bring a software release into production. Such events often end with bringing the software somehow into production—because from a certain point the path back to the old version is even more dangerous and difficult than the path ahead. However, the installation of the release is then often followed by a long phase in which the release has to be stabilized.
1.2.1 Continuous Integration Creates Hope
Nowadays it is the release into production that represents a challenge. Not so long ago the problems started much earlier: Individual teams worked independently on their modules, and prior to the release the different versions first had to be integrated. When the modules were put together for the first time, the system frequently did not even compile. Often it took days or even weeks until all changes were integrated and compiled successfully. Only then could the deployments commence. These problems have mostly been solved by now: All teams work on a shared version of the code that is permanently automatically integrated, compiled, and tested. This approach is called Continuous Integration. The required infrastructure for Continuous Integration is detailed in Chapter 3, “Build Automation and Continuous Integration.” The fact that the former problems associated with this phase have been solved raises hopes that there will also be solutions for the problems arising during the other phases leading up to production.
1.2.2 Slow and Risky Processes
The processes in the later phases are often highly complex and elaborate. In addition, manual steps render them very tedious and error-prone. This is true for the release into production, but also for the preceding phases—for example, during testing. Especially during a manual process, which, to make things worse, is only performed a few times per year, errors are likely to occur. This of course contributes to the risk associated with the overall procedure.
Because of the high risk and complexity, releases are not very frequently brought into production. In the end this causes the processes to take even longer due to lack of practice. In addition, this makes it difficult to optimize the processes.
1.2.3 It’s Possible to be Fast
On the other hand, there are always possibilities to bring a release rapidly into production in an emergency—for instance, when an error has to be urgently repaired. However, in such a case all the tests and therefore all the safety nets, which are an integral part of the standard process, are omitted. This is of course a pretty high risk—there are good reasons to normally run those tests.
Therefore, the normal path into production is slow and risky—and in emergencies the path can be faster, but at the expense of even more risk.