10 Jenkins alternatives for developers continuous delivery (CD)

Continuous delivery vs. continuous deployment: Which to choose?

Continuous delivery and continuous deployment both compress and de-risk the final stages of production rollout. Learn how to choose the proper path for your organization.

Most organizations today rely on a pipeline process to build and check in software, with rapid feedback to determine when the build broke and what change broke it. For the final step of production deployment, compile checks and unit tests have less value in a world of interpreted languages, web apps and APIs. Instead, continuous delivery and continuous deployment speed up deployments with less risk, and shift quality to the right into the purview of operations staff.

But which deployment path is right for you? A closer look at continuous delivery vs. continuous deployment will help reveal which is the most valuable for your organization right now.

The path from continuous integration to continuous delivery and continuous deployment

A CI/CD pipeline begins with continuous integration (CI), a process that collects and integrates code. Exactly what "integration" means can vary by team and organization; originally this meant mostly to run the compile step, but today this can include security checks, scanners for common mistakes that might compile and unit tests. When tests fail, the CI server knows exactly which commit (and which author) introduced the change, and notifies the author to fix the error.

Once the code passes tests, it can deploy automatically (continuous deployment), or notify a human who performs final checks and then triggers a deployment (continuous delivery).

Continuous delivery and continuous deployment setups compress the deployment process and ensure the checking is consistent, which reduces risk. These automated deployments rely on a focus on monitoring and rollback capabilities. They also require an exhaustive set of automated tooling or processes to deploy small subcomponents that carry minor risk

Continuous delivery in practice

Once code goes into version control, it is tested, fixed and rolled out. Steps along the way often include building unit tests, creating a virtual server, then running more automated, high-level checks against the server. If any step fails, the build fails. The developer is notified, typically by email, to fix the errors. Once everything passes the tests, the code goes to a final stage gate before it is deployed.

Illustration of the continuous delivery process.
The continuous delivery process involves several stages of checks, gates and feedback loops, before final test acceptance and push to production.

The DevOps book Continuous Delivery: Reliable Software Releases Through Build, Test, and Deployment Automation, summarizes the continuous delivery concept: "Automate the build, test and deploy process so that, if there are no problems with the software, it only takes one additional click to send it to production."

That final click triggers the actual deployment. In the illustration above, completion of the automated acceptance test generates feedback all the way back to the delivery team for human acceptance tests. In this step, the system sends an email to a tester, product owner or customer service representative to explore and double-check the environment. When they approve, the code rolls to production.

Testing isn't the only reason for this step. A product owner styling the user interface might want to roll together a set of changes. The company might roll out all the changes in a sprint at the same time for a final regression burndown check, or perhaps a specific day and time to mitigate business risk or target groups of users. In some cases, architectural constraints may prevent rollout of micro-features or micro-commits.

Once a team advances the pipeline from commit to ready, with deployments decoupled and able to happen several times per day, the team has achieved continuous delivery. Replacing this final human check with automation is the key difference with the other CD model -- continuous deployment.

Cl/CD in the cloud

A single test environment may seem quaint to many companies, perhaps from a different age. Today's continuous integration tools can create a different test environment for each version of the software. These tools can even live in the cloud and run through a web browser. In that kind of environment, moving from continuous delivery to continuous deployment might be a matter of moving a workflow step -- only the testers or employees can see the change, which is then tested on production and promoted to everyone or reverted if need be.

Progressive organizations that use CI/CD tools in the cloud may be better off starting with a system that can do continuous deployment, and build the ability to fall back in light of quality problems. Leave the "crawl-walk-run" cadence of deployment to the legacy systems, if you can.

Practicing continuous deployment

In a continuous deployment shop, when the test suite passes, changes roll out to staging. Obviously, this introduces risks, so organizations typically use various counter measures, such as:

  • Configuration flags. When a change rolls out, it only impacts a small subset of users, typically just employees or even just testers. Features can be expanded to a larger category of users with a simple bit flip in a database or a text file.
  • Deployment of isolated components. Etsy, an early proponent of continuous deployment, used the PHP programming language so it could deploy every separate webpage as a .php file, similar to the old .html files. A typical page might have some JavaScript and a style sheet, but unless that code includes a code library, the deploys can be separate. This also applies to software that separates the front end (graphics) from the middle tier (APIs).
  • Automated contracts. API and code specifications define what the software "should" do, and if it is still "working" at a modest, basic level.
  • Versioned interactions. Major version updates to an API can break changes. To fix this, have the code call a specific version of the API. Minor version changes do not change the aforementioned contract, interface or expected results.

To make continuous deployment work, your organization needs both architecture and infrastructure that support frequent deployments, some of the de-risking self-support mechanisms above and skilled staff to quickly produce high-quality code quickly.

Making the choice: Continuous delivery vs. continuous deployment

Most organizations will find it's relatively straightforward to adopt a continuous delivery process -- perform a build step, run unit tests, and if the unit tests pass, push the build to a dev or test server. (Shifting from continuous delivery to continuous deployment is harder for many organizations.) More traditional organizations with isolated development, test and staging servers can deal with some instability in dev, but this involves human intervention at several stages (push to test on tests passing, push to test after human exploration passes, then push to production). This slows the entire process, but with expectations that each step improves quality.

Legacy software teams that want to skip to continuous deployment will likely find that it won't work for a variety of reasons. For example, the software is deployed as one large compiled program file, and requires thirty seconds or more of downtime. Perhaps the deploys are not isolated, or the APIs are not versioned, or the system lacks automated contracts. These teams might be better off to start with continuous delivery and adjust the risk measures a bit at a time until continuous deployment is more viable.

Dig Deeper on Systems automation and orchestration

Software Quality
App Architecture
Cloud Computing
Data Center