Continuous Integration, Delivery, and Deployment (CI/CD)
What are the differences between Continuous Integration, Continuous Delivery, and Continuous Deployment?
Section titled “What are the differences between Continuous Integration, Continuous Delivery, and Continuous Deployment?”CI, CD, and the other CD are strategies addressing different steps of the deployment process. CI is more philosophical and it’s practice can vary from team to team and developer to developer, even those working on the same application. The two CDs are similar approaches to deployment, with Continuous Delivery requiring manual deployment and Continuous Deployment being automated.
- Continuous Integration (CI) refers to the practice of merging changes developed on feature branches back into main as often as possible. This practice relies heavily on thorough test coverage, as frequent merges increase the chance of merging broken code into the live application. With robust test coverage, however, CI helps many developers collaborate on a single application and avoid merge conflicts or bugs pushed to release or main branches.
- Continuous Delivery (CD) is the practice of automatically deploying code to a staging environment after your build succeeds and tests pass, then manually deploying to production after a person (often the client) reviews the changes. Teams using a Continuous Integration strategy often are also using a Continuous Delivery strategy. Many teams get on a regular delivery cadence, pushing changes to production weekly or at the end of a sprint. However, teams with truly agile CI/CD strategies deploy small changes as often as possible in an attempt to minimize the changes in each deployment and isolate issues that make it to production faster.
Continuous Deployment (the other CD) is the practice of automating your deployment to production after a successful deploy to staging. This requires even more robust and thoughtful test suites, as the deployment process is out of the hands of humans once a build succeeds. If all tests pass, that code goes live, even if it contains bugs or unexpected behavior changes.
What are the benefits of each strategy?
Section titled “What are the benefits of each strategy?”Continuous Integration:
Section titled “Continuous Integration:”The benefits of CI include fewer bugs making their way to production, fewer integration issues, less time spent on manual QA, less context switching, and increased confidence in shipped code.
In order to see these benefits all devs on your team must be committed to writing tests for all work (even bug fixes!) and merging their changes at least once a day.
Continuous Delivery
Section titled “Continuous Delivery”The benefits of CD include more frequent releases, faster iteration and implementation on small changes or fixes, and more people on the team being able to deploy changes.
In order to see these benefits your code needs to have sufficient test coverage and someone still needs to start the deployment process manually.
Continuous Deployment
Section titled “Continuous Deployment”The benefits of this CD include even faster development process, (theoretically) safer releases, bugs that are easier to track down and fix, and an application that is constantly improving without big scheduled releases.
In order to see these benefits your test coverage must be impeccable and your the documentation explaining the deployment process must be thorough and always up-to-date. There is more up-front work in setting up a Continuous Deployment strategy as well, but once the team is confident in the test coverage, pipeline, and documentation, deployments are no longer a part of a developer’s responsibility.
How much of each CI/CD strategy does Planet Argon use on client projects?
Section titled “How much of each CI/CD strategy does Planet Argon use on client projects?”Currently, Planet Argon has a strong culture of Continuous Integration, at least when it comes to test coverage. Our developers write new tests for their own work and often spend time adding tests to code that was written by previous developers. The percentage of test coverage varies across projects since not all clients are willing to spend project budgets on back-filling tests, but our internal commitment to CI is still strong and we are often able to convince our clients of the value of this strategy.
NOTE: The place where our CI strategy needs to improve internally is rebasing into master after merging changes into production. This merge workflow issue is something that we’ve discussed as a team and have steps outlined for improving in the future. Until we can get better adherence to this practice, CI will remain imperfect and will affect our ability to fully embrace Continuous Deployment.
Continuous Delivery is less consistent across client projects. Because we inherit legacy applications with existing deployment processes, we can’t always implement a CD strategy that complements our CI work. On projects where we are able to own CI/CD pipelines entirely, we practice Continuous Delivery pretty well. However, some clients do not give us access to those pipelines, and some clients even manage the deployment of their apps themselves.
Finally, none of our current client projects have a Continuous Deployment strategy in place. At best, we have CI/CD pipelines in place that push to a staging environment after a successful build and all tests pass, and from then we manually deploy from staging to production. On some projects we deploy to staging and our client or their dev team deploys our changes to production.
Helpful Resources
Section titled “Helpful Resources”Continuous integration vs. delivery vs. deployment
Continuous Integration vs. Continuous Delivery vs. Continuous Deployment
Continuous delivery and continuous integration - AWS CodePipeline