After the binaries have been built and after, or during, the software quality is being verified, the enterprise application will be deployed. There are usually several environments for testing purposes, depending on the project circumstances, such as test or staging and, of course, production. As mentioned earlier, these environments should be as similar as possible. This vastly simplifies the deployment process orchestrated by the CI server.

The process of deploying the application generally takes the binaries in the version that has just been built and deploys them onto the environment. Depending on what the infrastructure looks like, this can take place using plain scripts or more sophisticated technology. The principle should be the same, the binaries as well as the configuration are made available to the environment in an automated and reliable way. Preparation steps that are potentially required by the application or the environment will be executed in this step as well.

Modern environments such as container orchestration frameworks support infrastructure as code. Infrastructure configuration is captured in files in the project's repository and applied to all environments at deployment time. Potential differences, such as Kubernetes config maps contents, are represented as different manifestations in the repository as well.

Using IaC as well as containers provides even more reliability than home-grown shell scripts. The application should always be rolled out in an idempotent way, independent of which state the environment was in. Since container images contain the whole stack, the outcome is the same as if the software was installed from scratch. Required environment configuration is applied from IaC files as well.

New container image versions can be deployed by orchestration frameworks in many ways. There are certain commands that explicitly set Docker images used in Kubernetes deployments. However, in order to fulfill the requirement of reliability and reproducibility, it makes sense to only edit the infrastructure as code files and apply them on the cluster. This ensures that the configuration files stay the single source of truth. The CI server can edit the image definitions in the IaC files and commit the changes to the VCS repository.

As seen in the previous chapter, Docker images are specified in Kubernetes deployment definitions:

# deployment definition similar to previous chapter
# ...
    spec:
      containers:
      - name: hello-cloud
        image: docker.example.com/hello-cloud:1
        imagePullPolicy: IfNotPresent
        livenessProbe:
# ...

These image definitions are updated within the CI server process and applied to the Kubernetes cluster. The CI server executes Kubernetes commands via the kubectl CLI. This is the standard way to communicate with Kubernetes clusters. kubectl apply -f <file> applies the infrastructure as code contents of a file or directory containing YAML or JSON definitions. The pipeline step executes a command similar to this, providing the updated Kubernetes files which were updated in the project repository.

Following this approach enables that infrastructure as code files both contain the current state of the environments as well as changes made by engineers. All updates are rolled out by applying the Kubernetes files in the corresponding version to the cluster. The cluster aims to satisfy the new desired state, containing the new image version, and will therefore perform a rolling update. After triggering this the update, the CI server validates whether the deployment has been executed successfully. Kubernetes rollout actions can be followed by commands similar to kubectl rollout status <deployment>, which waits until the deployment is either rolled out successfully, or failed.

This procedure is executed on all environments. If single deployment definitions are used for several environments, the image tag definition only has to be updated once, of course.

To give a more concrete example, the following shows a potential configuration file structure of a Maven project:

The hello-cloud.yaml file contains multiple Kubernetes resource definitions. This is possible by separating each YAML object definitions with a three-dashed line (---). It's equally doable to provide separate files for each resource type, such as deployment.yaml, service.yaml, and so on. Kubernetes can handle both approaches. The kind type definitions in the YAML objects indicate the type of the resource.

The previous chapter showed how container orchestration frameworks enable zero-downtime deployments out of the box. Applying new image versions to the environments orchestrated by the CI server also accomplishes this goal. The environments will therefore be able to serve traffic with at least one active application at a time. This approach is especially important for production environments.