DevOps is neither a tool nor a job title: it is an engineering culture that tears down the historic wall between those who develop the software (Dev) and those who run it in production (Ops). At the heart of that culture sits the CI/CD pipeline, an automated chain that takes each code change and carries it, with continuous verification, all the way to users. This article explains in technical detail what continuous integration, continuous delivery and continuous deployment mean, how a real pipeline is built in GitHub Actions and GitLab CI, and which metrics prove the system works.
Continuous integration, continuous delivery and continuous deployment: three distinct concepts
The CI/CD acronym hides three practices that are worth keeping separate. Continuous integration (CI) means each developer merges their changes into the main branch several times a day, and each merge automatically triggers the build and the full test suite. Its goal is to detect conflicts and incompatibilities in hours, not weeks.
Continuous delivery extends CI: every change that passes the tests is packaged and kept ready to deploy at any moment, but the jump to production requires manual approval. Continuous deployment removes even that approval: if all checks pass, the change reaches production on its own. The difference between the two "CD"s—delivery versus deployment—is precisely that human button, and choosing one or the other is a governance and risk decision, not a technical one.
Anatomy of a pipeline: the stages that must not be missing
A mature pipeline chains together stages in which the cost of failing rises and the "blast radius" shrinks if it fails early. The canonical stages are:
- Build: compilation and construction of the artifact (binary, container image, package). It must be reproducible and start from a clean state.
- Unit and integration tests: they validate the business logic. Coverage is measured here, although coverage alone does not guarantee quality.
- Static and security analysis (SAST/SCA): linters, vulnerable-dependency scanning and code analysis. This is the place to "shift security to the left" (shift-left security).
- Artifact packaging and publishing: immutable versioning of the image in a container registry.
- Deployment by environment: first to staging, then to production, ideally with low-risk strategies such as blue-green or canary.
A golden principle runs through the whole pipeline: build the artifact only once and promote exactly that artifact across environments. Rebuilding for production introduces the risk that what is deployed is not what was tested.
GitHub Actions versus GitLab CI: how it takes shape
Both platforms describe the pipeline as YAML code versioned alongside the application, which satisfies the pipeline-as-code principle. In GitHub Actions the workflows live in .github/workflows/, are organised into jobs and steps, and reuse community building blocks through actions. In GitLab CI the configuration lives in .gitlab-ci.yml, is structured into stages and jobs, and takes advantage of native integration with GitLab's own container registry and issue tracking.
| Aspect | GitHub Actions | GitLab CI/CD |
|---|---|---|
| Configuration file | .github/workflows/*.yml | .gitlab-ci.yml |
| Organisation unit | Jobs and steps | Stages and jobs |
| Reuse | Actions marketplace | include templates and CI components |
| Runners | GitHub-hosted or self-hosted runners | Shared or specific runners |
| Integrated model | GitHub ecosystem + packages | Complete DevOps platform from a single vendor |
The choice rarely depends on technical capability—both cover the full cycle—but on the ecosystem the team already lives in and on the preference for an all-in-one platform (GitLab) over a modular, open model (GitHub).
Infrastructure as code and secrets management
A pipeline that deploys needs infrastructure to deploy onto, and that infrastructure must also be code. Tools such as Terraform (declarative, geared towards provisioning cloud resources) or Ansible (geared towards configuring machines) make the environment reproducible, versioned and reviewable through pull requests. The operational consequence is enormous: recreating a complete environment stops being a manual ritual of hours and becomes the execution of a plan.
The most delicate point of the pipeline is secrets management. Credentials, API keys and tokens must never be written in the YAML or in the repository. They are stored in dedicated vaults—GitHub Secrets, GitLab protected variables, or managers such as HashiCorp Vault—and injected at runtime with the minimum privilege necessary. Current trends such as OIDC authentication let the pipeline obtain temporary credentials from the cloud provider without storing any long-lived secret.
Alongside secrets, two practices raise the maturity of the pipeline. The first is storing the infrastructure state remotely and locked (for example, Terraform's state in a bucket with locking), so that two simultaneous runs do not corrupt the environment. The second is the use of ephemeral review environments: each pull request automatically spins up a disposable copy of the application where the change can be reviewed live, which is destroyed on merge. This way the review stops being a reading of code in the abstract and becomes a real functional check, without contaminating shared environments or leaving orphaned resources eating into the budget.
DORA metrics: how to know whether DevOps is working
The DORA research (DevOps Research and Assessment) proposed four metrics that correlate with software delivery performance, today a sector reference:
- Deployment frequency: how often code is shipped to production.
- Lead time for changes: how long it takes a commit to reach production.
- Change failure rate: what percentage of deployments cause a degradation that requires remediation.
- Time to restore service: how long it takes to recover from an incident.
The key nuance is that these metrics do not pull against each other: high-performing teams deploy more often and with a lower failure rate. Speed done right is the consequence of stability, not its enemy. They should also be read as a set and never in isolation: optimising only deployment frequency without watching the failure rate and the time to restore produces teams that ship fast but break production often, which destroys trust and ends up slowing real delivery. The balance among the four metrics is, in itself, the health indicator of the process.
Common mistakes when implementing CI/CD
- Slow or flaky tests. A pipeline that takes forty minutes or that fails at random erodes confidence and pushes people to skip it.
- Rebuilding per environment. Generating different artifacts for staging and production breaks the guarantee that what is deployed is what was tested.
- Secrets in the repository. The most frequent security mistake and the most expensive to reverse, because a leaked secret must be rotated even if it is deleted from the history.
- Deploying with no rollback strategy. Without automatic rollback or feature flags, any faulty deployment turns into a prolonged incident.
- Automating chaos. If the manual process is broken, automating it only produces failures faster; first you fix the process, then you automate it.
Frequently asked questions
What is the real difference between continuous delivery and continuous deployment?
In continuous delivery the software is made production-ready automatically, but the final jump is authorised by a person. In continuous deployment there is no manual approval: if all tests pass, the change reaches production on its own. The choice depends on the maturity of the tests and on the business's appetite for risk.
Do I need containers to do CI/CD?
It is not mandatory, but containers (Docker) make reproducibility vastly easier: the same artifact runs identically on the developer's laptop, in the pipeline and in production. You can do it without containers too, but it increases the risk of differences between environments.
What are the blue-green and canary strategies?
Blue-green keeps two identical environments and switches traffic from one (the old version) to the other (the new one) all at once, with instant rollback. Canary releases the new version to a small percentage of users, observes metrics and expands gradually if all goes well. Both reduce the blast radius of a faulty deployment.
Where should a company with no pipeline at all begin?
With basic continuous integration: automating build and tests on every merge to the main branch. Once that foundation is reliable, you add security analysis, artifact packaging and, finally, automated deployment by environment.
Conclusion
The value of a CI/CD pipeline is not measured by how sophisticated the YAML is, but by one concrete property: that shipping a change to production stops being a stressful event and becomes a boring, safe routine. When building once, testing thoroughly, managing secrets outside the code and deploying with reversible strategies become part of the normal workflow, the DORA metrics improve on their own and the team recovers the time it used to spend fighting fires. That is the real promise of DevOps: not deploying faster for the sake of speed, but removing the fear of deployment. At Summum Systems we design and implement pipelines in GitHub Actions and GitLab CI tailored to each team's maturity.