Skip to content

Overview

Deploying infrastructure and code frequently can be complicated and highly error prone if performed manually. Automating this process is critical to ensure that you can perform this frequently and reliably.

Integration with CI

Organizations see the obvious benefits of using containers as a way to facilitate development, deployment and environmental orchestration. Containers effectively manage environmental differences, provide predictability that enable Continuous Delivery (CD) of new functionality. Users can quickly integrate with their existing CI tools such as

Developers can quickly automate manual, repetitive, time-consuming tasks. For example:

  • Cluster provisioning
  • Deploy workloads using a GitOps pattern
  • Update/Upgrade/Rollback workloads with zero downtime

CI/CD Helper Repo

Tip

Access the CICD Helper Git Repo here

We develop and maintain a public Git repository with functioning illustrative examples of integrations with common CI platforms. Users are welcome to leverage, extend and contribute examples.

GitOps

A typical GitOps workflow will provide a path from code to production “in a few easy steps!". An illustrative example is shown below

  1. Make a feature branch
  2. Push that branch and open a PR. This gets built and deployed to the developer's TESTBED. This can be used to test the changes and iterate until it is ready.
  3. Merge the feature branch to master. This triggers a build and a deployment to a STAGING environment.
  4. Once the staging environment reaches a state that is ready for production, tag a release
  5. The tag gets deployed to PRODUCTION using the same container that was built for staging, but using production configuration.

An end-to-end example of a CI-CD Pipeline based on Git and Jenkins is displayed below.

Example CICD Pipeline

Recommendations

Make Containers Immutable

Docker allows you to rewrite a tag when you push a container.

We strongly recommend that customers take the approach that all tags are immutable i.e. a unique value such as commit ID. This directly connects a container to the code that it was built from and erases any doubt that we know exactly what is inside that container.

Using "latest" as the container tag is a very dangerous practice because it presents scenarios where you don’t know what code is running in your container.

Keep Configuration Outside Container

A container should be considered an immutable artifact of our build process. The configuration should never be embedded in the container itself.

Deployment of the container should be driven by the environment (cluster) and should never require changes to the container itself.

Use A Git-Based Workflow

All CI/CD pipelines should be triggered by Git operations because this strongly aligns with a standard developer workflow, and makes the pipeline more accessible to developers. It also strongly aligns with the immutability of a container being tied to a commit ID.