Continuous Integration, Delivery, and Deployment
Continuous Integration, or CI for short, is the process through which developers automate the building and validation of code to ensure quality check-ins. Every check-in is passed through a number of tests that help pinpoint issues early in the development lifecycle.
Continuous Delivery builds upon Continuous Integration and adds a series of practices that ensure the code is always ready to be deployed to production at the click of a button. If at a moment’s notice someone decides that the current integrated branch should become the de facto production version, nobody will question the stability and quality of the codebase when it’s deployed to production.
Finally, Continuous Deployment ensures that once all the tests are passed and there are no conflicting issues, all changes are automatically pushed to a production environment. While you can think of it as the next step after Continuous Delivery, it is also a way to make releases as painless as possible, where developers are comfortable with their changes becoming public with no additional effort, while also not stressing about large-scale disruptions as every piece of code is validated using automation before deployment. Table 6.2 summarizes the three processes.
Figure 6.2 shows how each microservice in the Flak.io project defines its own GitHub repository, continuous integration process, and independent continuous delivery pipeline, enabling each service to ship independently of each other. Docker images are built during the continuous integration process and are pushed into a central, private Docker registry. Doing so ensures production realism in that the Docker image that is running in Dev is the same image running in Production, with only per-environment configuration changes, discussed later in this chapter.
