Deploying a Microservice with Continuous Delivery
In this section we’ll discuss how code flows from check-in to production in a continuous delivery pipeline as shown in Figure 6.5.
1. Continuous Integration is when a developer checks in code, a build is automatically triggered, and a set of unit and consumer contract tests (discussed later) are run against the build. If the tests pass, we execute a docker build command to build an image and set the version number for the new service. Once the image is built, it is pushed to a Docker Registry (see Chapter 4, “Setting Up Your Development Environment,” for Docker Registry hosting options).
2. Create containers in different environments. One of the most important differences between traditional deployments and Docker deployments is that once the Docker Image is built during the CI step, you never again access or build source code in other environments. Instead, you create instances of containers based on the image that was pushed into the Docker Registry during the CI process. Doing this enables teams to get closer to production realism, where the same exact image that was tested in development is run in production. To create a container in an environment, you have a few options. You can call docker run to create an image from your Docker repository, or you can use multi-container configuration files like Marathon or Docker Compose to create your container and any interdependent containers it requires.
3. With the microservice now packaged as a Docker image, the Dev environment pulls the set of Docker images that make up the microservice so that developers who need to see a “Dev” version of the microservice have a sandbox for developing and testing their service.
4. Like the Dev environment, the QA environment also pulls and creates Docker containers to run automated tests like integration tests, coded-UI tests, or load tests to further validate the quality of the build. If the tests pass the QA environment, this triggers a deployment to the staging environment.
5. In the staging environment, the set of Docker images that make up the microservice are again pulled from the Docker Registry and we are now ready for production. At this stage, there could be a set of manual tests or user acceptance tests to validate that the service is working well against a more production-like environment. As the dotted line between staging and production shows, the promotion of the microservice from staging to production is manual for continuous delivery.
6. Once the team is ready to promote to production, the production environment again pulls from the Docker Registry to create the Docker containers needed to run in production and a new set of tests are run in production to further validate the quality of the deployment.