Continuous Integration and Continuous Deployment

The key to success with CI/CD is to automate and monitor as much as you can practically. A well-tuned CI/CD pipeline will help your organization quickly deliver quality code to your customers.

Continuous Integration

Continuous Integration is a development practice that ensures your application is always in a “good” state. This means that anything in your master or pre-production branch is in working order and never stays broken for long.

CI is all about taking the code written by developers and compiling it into an artifact, running automated tests, and capturing the log files so any failed builds or tests can be resolved. A CI server facilities this process by running builds and tests with each commit.

The CI process can be described as :

code + dependencies + build tools + execution environment = test results + logs + compiled artifact

The left side of the equation takes the code written by developers, any dependencies of the code, a build tool, and the environment where the build and tests are executed. When these inputs are available, a CI server completes the build to produce the elements on the right side of the equation.

When a CI server has been configured correctly, each commit to a repository results in the build being run, and thus solving the equation without any manual intervention from a human.

This means that the CI process is machine-driven, so much so that it is common for CI servers to have read-only user interfaces, like the Jenkins Blue Ocean UI.

Continuous Deployment

CD takes the compiled artifacts from a successful build performed by the CI server and deploys them into the production environment. In this scenario, CD is quite rightly an extension of CI, and the distinction between the two becomes arbitrary.

Such commit-to-consumer pipelines are common in simple projects. More complex projects can also have a completely automated development pipeline, so long as the appropriate tests and monitoring systems have been put in place.

But while fully automated deployments have many benefits, it is not uncommon for deployments to involve human decision making. There are many valid reasons for not automatically deploying every commit to the master branch into production, including:

• Coordinating deployments with legacy systems.
• Acquiring sign-off from product owners.
• Usability testing that is impossible to automate.
• Regulatory requirements.
• Dogfooding your own product.
• Integrating deployments with backend changes like databases.
• Not having 100% confidence in your tests.

Where CI is machine-driven, for many teams, CD is human-driven. Much of the grunt work of performing a deployment will still be automated, but the decision to promote a release through to production is a human one.