Chapter 5. How to Set Up Continuous Integration and Continuous Delivery
In Chapter 4, you learned several tools that help developers work together, including version control, build systems, and automated tests. But merely having a collection of tools is not enough. You also need to know how to put them together into an effective software delivery lifecycle (SDLC). Every company has its own SDLC, some of which work better than others.
For example, at LinkedIn, before Project Inversion (which you read about in the Preface), our SDLC was based on a release train model: every two weeks, a “train” would leave the station with new code destined for production. At the time, teams did their work in isolated feature branches, and to get on the train, you needed to get your code into a release branch. Several weeks before a scheduled release, we would do integration, merging feature branches into a release branch, followed by deployment, rolling out the release branch to production.
The integration process frequently ran into problems. As dozens of feature branches came crashing together, developers would find that they had been coding for months on top of incorrect assumptions. The API you were using in a dozen places had been removed; the module you had updated had been refactored in an incompatible way; the new feature you added no longer looked right because of a design change. Resolving these conflicts could take weeks.
The deployment process was also problematic. For each release, ...