Andrea Danti - Fotolia
Clear up CI vs. CD confusion for DevOps practices
How do CI and CD differ? And how should development shops distinguish between the two? Learn more about the processes and how they've valuable in a DevOps environment.
Continuous integration and continuous delivery have become more commonplace in software development, but a lot of confusion around these terms still exists. While the processes are closely aligned, it's important to know how CI and CD differ, as well as how they fit into the broader DevOps movement.
Accelerated, but safe, code delivery and continuous feedback are big draws of CI/CD -- and, in turn, faster code releases and continuous feedback are central to DevOps. It's not uncommon to see the terms CI/CD pipeline and DevOps pipeline used interchangeably and, similarly, CI/CD tools listed as necessary tools for DevOps.
Let's examine CI vs. CD, and how each plays an integral role in DevOps.
What is CI?
To put it simply, continuous integration refers to processes a development team can use to safely integrate code into a shared version-controlled repository. These automated processes are triggered anytime a developer introduces new code.
For example, a project might have a CI/CD pipeline with three stages.
In the first stage, developers will locally write code and propose changes to the main repository. A development team tests these changes with a subset of the project's tests, which are designed to run quickly and give developers feedback they can use to improve their code before merging. Some examples might include unit tests, API tests or style-type tests to ensure code is reliable and readable, which are also known as linting. Speed is a key factor in this first stage, but it's important to balance that with tests that provide value. A short feedback loop means a developer can address that feedback right away. As the CI process goes on, these feedback loops grow longer.
After the first feedback loop is completed, a developer usually moves on to new work because they trust the automation to validate their changes. Coming back to previous work is a taxing mental shift that takes time away from new work. Rework, as it is referred to, often forces the developer to burn the same amount of time they originally spent on a feature, or even more. The length of time depends on the nature of the rework and the length of time between starting rework on a feature and when the development team originally implemented the feature.
Once the tests pass and the first feedback loop is closed, the new changes undergo further vetting. These more extensive tests in the second stage take longer and test deeper. For example, integration tests may require multiple applications or databases to run. Performance and load tests often take minutes to hours to complete. Depending on your application's requirements, this second stage can also be an ideal place to run compatibility tests, which might test your application in a range of different internet browsers or with different simulated connection speeds.
The goal in the second stage is to thoroughly test for quality. Because the new code has already passed the first stage, you can justify the extra time on deeper tests before you release the changes.
The final stage is to simply integrate the well-tested changes into production. It's important that developers have a place to store production code -- such as a main branch in any version-control system -- so they can easily track changes. This way you will know that these changes have made it through the previous stages. When bugs are discovered, it's also easy to revert to the previous version.
What is CD?
The CD in the CI vs. CD debate refers to continuous delivery, which is the automated process of taking these changes and delivering -- or deploying -- them as a package to a live environment. Oftentimes, an organization will conduct even more thorough testing at this stage.
The idea with CD is that new code can reach customers, where it creates value, as soon as possible and when the business decides it is best. As an added benefit, the automation required to release features with the click of a button removes potential human error opportunities because it replaces deployments done by hand.
A further level of automation -- which needs no manual intervention at all -- is called continuous deployment. Continuous deployment uses everything from continuous integration and continuous delivery, but it removes the final manual decision point and automatically deploys a change to production once it advances through all of the automated integration stages.
Where testing fits into the CI vs. CD fold
Using a process like this requires not only thorough testing in the CI stages, but also strong confidence in those tests. The benefit is two-fold. First, you create an even quicker turnaround between the developers who create features and the customers who use them. Second, you reduce the time necessary to perform manual production deployments tasks, which are prone to human error.
For an organization new to automation in general, start with CI and build a proper pipeline with tests that add value to the project. Once there's comfort with the CI pipeline, consider continuous delivery, and then add automated deployments. These will also allow you to test more extensively and run tests that wouldn't be possible without a fully functioning application.
Continuous deployment is best reserved for those organizations that have done continuous integration and continuous delivery for a while, and have confidence in their pipeline's ability to enforce quality. These companies aren't satisfied with the speed of continuous integration and continuous delivery, and, to them, the manual step of releasing to production is a hindrance rather than a useful check.
