Continuous Deployment Tools That Earn Their Place

Six weeks after you start, the repository contains one pipeline file per service, a rollback that has fired against production at least once in anger, and a deployment log naming the commit, the image digest and the target environment for every release since the cutover. You can read that log and tell which change is live without opening a chat thread. That is the finish line.

The tools that earn their place produce those three artefacts with no human opening a ticket. Everything else, the dashboards, the AI summaries, the seat-based pricing, is a claim you can test against the log. The steps below run in the order they are done. Each one ends with an outcome you can check before starting the next.

The first service moved to continuous deployment ran on a pipeline on a laptop under someone's desk, with a rollback shell script that no person had executed since it was written. Four services later, the sequence that held was this one.

1. Put the pipeline definition under version control with the code

Configuration held in a vendor's web form cannot be reviewed, reverted or diffed. The Cambridge UIS DevOps guidebook says that a project's git repository usually contains the .gitlab-ci.yml file for job and pipeline configuration, and that pipelines group jobs while tracking their dependencies.

stages: [build, test, scan, deploy]

build-image:
  stage: build
  script: [docker build -t "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA" .]

Check: git log --follow .gitlab-ci.yml shows the pipeline changing in the same commit as the code that made the change necessary. Pipeline edits that arrive in their own commits leave you maintaining two repositories.

2. Fix the phases and let each one fail the pipeline

Octopus Deploy's 2026 CI/CD guide describes the pipeline in four phases: source, build, test, deploy. Give each phase at least one job whose non-zero exit ends the run.

Check: push a commit that breaks a unit test. The build job must not publish an artefact. A pipeline that builds successfully after a test failure publishes a status and leaves the merge ungated.

3. Build once, address the artefact by digest, and promote that digest

The build phase produces the container image or language package. Every later environment promotes the same bytes. The Cambridge guidebook describes publication to the Google Cloud Artifact Registry tagged with the version, ready for deployment, alongside its artifact-registry template that handles authentication to both the GitLab Container Registry and the Artifact Registry.

docker push "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA"
docker inspect --format='{{index .RepoDigests 0}}' "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA"

Check: the digest in the staging deployment record equals the digest in the production record for the same release. A staging rebuild deploys different bytes to users from the ones the tests passed.

4. Run security scanning inside the pipeline

The NCSC's secure development and deployment guidance outlines eight principles, and two land squarely on the pipeline. Principle 6 requires you to secure the build and deployment pipeline so that tooling cannot undermine code integrity and key security processes cannot be bypassed. Principle 7 requires you to continually test your security, automating security testing where possible so specialist staff can concentrate on subtle and uncommon weaknesses.

The Cambridge UIS standards treat dependency scanning, container scanning, code quality, secret detection and static application security testing as the baseline analysis jobs, with results attached as reports to the merge request. Their current position tracks dependency and vulnerability analysis running on merge requests while a new vulnerability does not yet block merging pending triage policy.

Check: open a merge request and find the scan report attached to it. A scan that emails a PDF to a security team remains outside the pipeline and outside the merge decision.

5. Carry staging and production in one pipeline definition

Two pipeline definitions drift. One definition with a single condition remains the same. In the Cambridge UIS model, any commit may deploy to development, staging deploys automatically on merge to the default branch unless configured otherwise, and deployment to development and production requires manual approval. City St George's, University of London reports AWS's definition of the boundary: continuous delivery differs from continuous deployment by the presence of a manual approval to update production.

Check: merge to the default branch. Staging updates with no click. Production maintains the same digest behind one approval. Delete the approval and the pipeline definition stays unchanged, because the approval was a condition on a job.

6. Automate the rollback before you automate the release

Harness's practical guide to continuous deployment places automated rollback in the same list as staging deployment and post-deployment verification, and describes recovery measured in minutes where the older process took hours. IBM's overview of continuous deployment identifies blue-green, rolling and canary strategies as the rollback mechanisms a deployment platform has to support.

The clearest version is canary analysis. The DevOps Training Institute survey of twenty companies shows Netflix deploying a new version to a small subset of users, comparing hundreds of metrics against the stable version, and triggering an automatic rollback on a rise in error rate or latency. The same survey reports Amazon deploying code every 11.7 seconds on average across its e-commerce and cloud infrastructure.

Check: your rollback has run at least once against production outside a game day. An untested path will not run when production needs it.

7. Template the pipeline so the second service costs hours

Harness reports that Ancestry cut developer effort eighty to one by implementing reusable features across its pipelines. Templates are how a platform team enforces a standard across every service without editing each pipeline file.

Check: onboard a second service. It inherits scanning, staging deployment and rollback from the template, and the only file you write names its build command and its port.

8. Read four numbers off the pipeline every month

The enlabsoftware review of continuous delivery identifies deployment frequency, lead time, change failure rate and mean time to recovery as the metrics to track. Get all four from the pipeline's own logs.

Check: each number has a query behind it. Deployment frequency counts production deploys. Lead time is the interval between the first commit on the merged branch and the production deploy. Change failure rate is the share of deploys followed by a rollback or hotfix inside the window. Mean time to recovery is the interval from failure detection to a healthy production deploy. Metrics assembled from a retrospective measure what people remember, which is the deploys that hurt and the deploys that were praised.

Where the tool classes change the sequence

The pipeline definition in step 1 is the axis that divides the classes, because whatever contains that file determines how much of the rest of the sequence you own.

GitLab CI/CD keeps the pipeline in .gitlab-ci.yml, and the Cambridge UIS standards show its Auto-DevOps template supplying container image builds, dependency scanning, secret detection and code quality as standard jobs, which establishes step 4 partly in place before you write a rule.

Jenkins reaches the same state after you assemble and maintain the plugins, which prices step 4 in engineer time and makes step 1's review more valuable, because plugin drift is a class of change that only shows up in the diff.

CircleCI and GitHub Actions run the pipeline as a hosted service, which removes the runner fleet from your operations budget and keeps step 1 as a YAML file you still own. The trade is step 3: the artefact moves through a vendor's registry with its own retention and authentication rules.

AWS CodeDeploy and IBM DevOps Accelerate start at step 3. They assume an artefact exists and take over the promotion, the traffic shift and the rollback, which leaves steps 1, 2 and 4 with whatever system built the artefact. IBM's overview describes these two along with Azure DevOps, GitHub Actions, GitLab CI/CD, Jenkins and CircleCI, and divides their capabilities into multicloud deployment blueprints, distributed automation, quality gates and approvals, and tested integrations provided as prebuilt plug-ins.

Azure DevOps covers steps 1 to 5 inside one product and leaves the rollback design in step 6 to the team that owns production.

A tool that supplies templates and environment-aware permissions moves step 7 off the critical path of the second service. A tool that supplies only a build runner leaves steps 5, 6 and 7 on your desk, and the desk is where the six weeks go.