What is the Difference Between Continuous Deployment and Continuous Integration?

continuous deployment vs continuous integration

Software development life cycles are becoming shorter, pushing development teams to pursue even faster development and deployment methodologies that allow them to remain competitive without sacrificing product quality. In order to achieve this, many teams have turned to continuous integration and continuous deployment (CI/CD.) These two terms often go hand-in-hand, but they refer to two distinct concepts that will be covered in detail in this article.

How Continuous Deployment Fits Into DevOps

Continuous deployment is an automated deployment process whereby new commits to a project’s main repository branch are pushed to the production environment as soon as they pass testing. This is in contrast to traditional DevOps approaches, such as agile sprints, where new changes are instead accumulated and pushed to production in large batches after discrete development and testing stages. This elongated development and testing process worked well about a decade ago, but today it cannot compete with top performing software teams. Instead, commits both large and small are pushed to production as soon as possible.

This allows teams to continuously push new features on a regular basis, keeping their product on the cutting edge in a highly competitive market. It also means that teams can respond to customer feedback very quickly, and developer velocity can be higher. However, this can be a double-edged sword, as testing and quality assurance processes need to be watertight or teams risk pushing buggy code straight to production.

Continuous deployment is favored by many software teams as it is ripe for automation and massively simplifies the process of deployment once those systems have been put into place. This is because there is little need for manual intervention once a continuous deployment process has been put into place. To err is human, so removing humans from the deployment process (which can be a white-knuckle experience even for the most senior developers) as much as possible reduces the surface area of those most human of potential mistakes, such as simple oversight and forgetfulness, that can sometimes lead to serious consequences.

Continuous Integration

Continuous integration refers to the DevOps philosophy of having developers merge their code into the main repository on a regular basis, often several times a day. This is in opposition to other practices that may encourage batching commits into larger chunks that are merged infrequently. Continuous integration has become the preferred method of development for several reasons.

Merge conflicts can be a pain to deal with, which are all the more exacerbated if commits come in large, infrequent batches and contain changes that touch upon many different files or areas of the codebase. This became even more apparent since the global pandemic pushed many teams towards working from home. When several developers check out the same file and each makes their own changes to it over the course of a few days or even weeks, it can become almost impossible to determine how to merge all those changes together and deal with inevitable conflicts; this is made all the more difficult for teams working from home or not in direct contact with each other.

A solution to this is to prevent multiple developers from pulling the same file simultaneously, but depending on the length of time a file is checked out for, this can be a very inefficient method of development and can negatively impact development velocity. Multiple developers may need to make changes to a particular file and will be forced to wait for their turn to modify it in order to avoid making conflicting changes with another developer. If they don’t have other work they can do, they are forced to sit idly by, and idle developers are expensive.

Batching many changes inside a single commit also makes it more difficult to track down the source of any bugs or defects that are introduced to a repository. Tracking down the commit that caused the issue can be difficult when each commit contains several modified files containing multiple unrelated changes, which in turn also makes it difficult to roll back a buggy commit without also undoing the other changes within that same commit, which may otherwise be perfectly ready to deploy.

Instead, by encouraging the continuous integration of smaller commits on a regular basis, it becomes much easier for developers to work in parallel with each other on the same files. Merges may be as small as a few lines of code within a file, which means that when conflicts do occur, it is a lot easier to manually resolve them. It also makes identifying problems within commits easier and means that rolling back a buggy commit results in more limited repercussions outside the scope of the file in question.

What About Continuous Delivery?

CI/CD can be a somewhat ambiguous acronym, as CD can refer to both continuous deployment and continuous delivery. Despite the matching initials, some argue that they are quite different concepts. Whereas continuous deployment refers to pushing changes to production on a regular basis, continuous delivery is about ensuring that a project’s codebase is always kept in a deployable state.

This is distinct from the idea that a codebase is feature-complete. Rather, it means that all the existing features within that codebase have been developed, tested, debugged, and in a state that could be pushed to production without issues at any moment, even if the project as a whole is not finished.

The impetus behind this idea is simple: it is a logical continuation of continuous integration and continuous deployment. If code is continually integrated within the main branch of a repository and continually deployed to production, then it stands to reason that code should always be in a production-ready state and therefore, if code is in a production-ready state, there should be no reason not to push code to production so that these changes reach end-users as soon as possible.

It is worthwhile to note that there is no formal delineation between continuous deployment and continuous delivery, and there are some schools of thought that argue the two concepts overlap and are either very similar or outright the same. Without formalized, industry-standard definitions to go by, it is left as an exercise to the reader to determine how distinct these two concepts are from each other.

CI/CD and Test Automation

The core concept common to both CI/CD is continuity. Code is continuously integrated and continuously deployed. These techniques clash with more traditional approaches to software development, such as agile, where code is first designed, developed, tested and then deployed. Sprints last two weeks, which allows teams to set aside ample time for testing. This often leads to test suites that may take multiple hours (or perhaps even have to be left overnight) to complete. In agile, this is perfectly acceptable, but teams that attempt this in CI/CD environments will quickly fall flat on their face.

When small commits are pushed and deployed on a continuous basis, manual testing becomes untenable. Human testers are simply too slow to keep up the pace. Likewise, test suites that take hours to run will quickly become backed up if commits are pushed on an hourly basis and each test suite takes multiple hours to run.

The solution to this problem is well-prioritized test automation. Automated tests should become part of the production pipeline – code gets integrated, then it gets tested, then it gets pushed to production (assuming it passes all tests, of course.) This is sometimes referred to as continuous testing and it is fast becoming a natural part of the CI/CD pipeline for many teams.

This requires careful consideration on behalf of the testing team. Tests need to be quick to run and written in a way that allows them to be automated, which is no small task if a team is used to relying on manual testing for even part of their test suite. Some areas of testing are easier to automate than others – unit tests are rarely run manually anyway, whereas end-to-end testing can be tricky to automate without the right tools and strategies in place. Many teams build automated end-to-end tests for every conceivable scenario and find themselves with a four-hour test suite anyway; they are left scratching their heads, wondering how to trim their test run time by an order of magnitude to keep up with their deployment strategy.

Designing and developing successful automated tests is a topic worthy of dedicated articles of its own, and much has been written on the subject already, which is well worth checking out for teams looking to implement continuous testing into their CI/CD pipelines.

Get a Handle on CI vs CD and Other Key Concepts

Hopefully, this article has helped to shed some light on what continuous integration, deployment and delivery are and the differences between the three. CI/CD and continuous testing have become popular in the software industry because they allow teams to move quickly without breaking stuff. Responsiveness is key in contemporary software development and users are impatient. Teams that stubbornly cling to ageing development methodologies will, sooner or later, find themselves out-competed by competitors that embrace more fast-paced development methodologies like CI/CD.

By no means is it easy to change an entire team’s development and deployment processes. Whether your team is large or small, overturning tried and true processes can be a struggle. Often, test automation becomes the hurdle that teams struggle most to cross, as there is precious little data to guide teams on how to build a leaner, faster test suite than the one they have. Continuous testing requires prioritization best driven by data: if such prioritization will help your business achieve CI/CD, talk to a product expert at ProdPerfect today.