Continuous Delivery in the Wild

Chapter 3. Running an Integrated System

In Chapter 2 we saw that participants strive for a continuous flow of small changes into production. This leads to two outcomes. First, preproduction environments become less useful. Second, engineers have to test their changes against an integrated system before merging those changes to master.

Continuous Delivery Demands Fewer Environments

Participants that had recently moved to Continuous Delivery, such as the Online Retailer, described a pre-CD world where engineers and testers relied on multiple fully integrated preproduction environments—environments running the full stack of software constituting the product, in a similar physical architecture to production (although often at a smaller scale). These preproduction environments are used for different use cases: developer sandboxes, integration testing, exploratory testing, showcasing, and so on.

Multiple environments were necessary because these different activities required different versions of various codebases to be integrated for inspection. For example, product manager might want to preview an upcoming release in an environment running the current release candidate for every codebase (a release candidate being the version that has been identified as ready for release to production, pending quality checks). An engineer might also want to work on a new integration between two services by pointing a locally running service to some feature branch version of a dependent service, running ...