A CI/CD pipeline turns a code change into a sequence of repeatable checks and release actions. This guide explains what continuous integration, continuous delivery, and continuous deployment mean, how the stages connect, and where people still need to make decisions.
How Do CI/CD Pipelines Work?
Continuous integration, or CI, combines frequent code integration with automated build and test feedback. Continuous delivery keeps validated changes ready for release, while continuous deployment releases qualifying changes to production automatically. A pipeline implements these practices, but passing it does not prove software has no defects or that every change is safe to release.
What CI and the two meanings of CD actually mean
Without regular integration, developers can accumulate changes that conflict with one another or depend on assumptions that no longer hold. CI encourages small, frequent integration and quick feedback about the shared codebase. The exact schedule depends on the team; simply running tests overnight is not the whole practice.
A pipeline is the automated sequence that supports that feedback. It may start when a pull request is opened, a commit reaches the main branch, or a release is approved. The details vary, but its purpose is to make the path from source to releasable software understandable and repeatable.
| Practice | Main question | Production decision |
|---|---|---|
| Continuous integration | Does this change integrate and pass defined checks? | Not necessarily included |
| Continuous delivery | Is this validated change ready to release? | Often an explicit approval |
| Continuous deployment | Does the change qualify for automatic release? | Automated under defined rules |
Teams sometimes use “CD” without specifying which meaning they intend. Clarify that distinction before discussing approvals or release frequency. Continuous delivery does not mean repeatedly performing a manual build; the release process should still be automated even if a person authorizes it.
Small changes can make faults easier to isolate, but size alone is not a safety guarantee. A one-line permission change can have substantial impact. Tests, reviews, rollout controls, and recovery plans still matter.
Follow a change through the pipeline
A typical flow begins with source control. A developer proposes a small change and the platform starts checks against the relevant revision. The runner is the machine or environment that executes the jobs; it is not necessarily the same infrastructure that serves users.
GitHub's documentation on Actions describes events, workflows, jobs, steps, and runners in one widely used implementation. Other platforms use similar building blocks with different names and execution rules. The important questions are what triggers work, what each stage consumes, and which result allows the next stage to proceed.
A build stage resolves dependencies and produces a runnable package, container image, or other artifact. Fast checks may run before expensive integration tests so that obvious failures return quickly. Independent jobs can sometimes run in parallel, while dependent stages must wait for earlier outputs.
The resulting artifact should be identified unambiguously and associated with its source revision. Where feasible, promote the same tested artifact through environments rather than rebuilding separately for production. Google's release engineering chapter discusses repeatable builds and release processes, which help explain why traceability matters.
Deployment then applies the artifact and configuration to an environment. A later verification step checks whether the application actually starts and performs essential operations. A successful upload is not the same as a successful user experience.
Design tests and gates around real risks
A pipeline usually combines several forms of evidence. Unit tests check small pieces of logic; integration tests check interactions; end-to-end tests exercise a broader user path. Static analysis, dependency checks, and configuration validation can address other risks, but no category substitutes for all the others.
Keep the earliest checks fast enough to support useful feedback. If every small change waits behind a long, unstable suite, developers may stop trusting results or delay integration. Diagnose slow and flaky tests rather than treating reruns until green as a release strategy.
A flaky test produces inconsistent results without a corresponding intended code change. Quarantining one may be a temporary measure, but assign an owner and a repair plan. Silently disabling important coverage leaves a gap that a green status conceals.
Release gates should correspond to a reason. A production approval may be appropriate for a sensitive business operation, a required separation of duties, or a change with difficult recovery. Avoid ceremonial approvals where nobody has useful evidence to review.
Also distinguish testing from deployment policy. A change can pass tests yet require a restricted launch because it introduces a database migration or alters billing behavior. Record exceptional handling in the workflow rather than relying on someone's memory at release time.
Work through a small release example
Consider a hypothetical team changing how an online shop calculates a delivery estimate. A developer adds tests for the new rule and opens a pull request. The pipeline checks formatting, runs unit tests, builds the application, and runs a test against a controlled shipping-service substitute.
Suppose those jobs take a hypothetical two, four, three, and five minutes respectively. If they run sequentially, they take fourteen minutes, excluding setup and queue time. If the first two jobs can run together and the last two must follow, the simplified critical path is twelve minutes. These invented timings illustrate dependencies, not expected pipeline performance.
After review and merge, the team creates a release artifact tied to the commit. The same artifact goes to a staging environment, where a smoke test checks that checkout still returns a delivery estimate. Staging uses separate credentials and safe test data rather than production customer details.
With continuous delivery, a responsible person may then approve production deployment. With continuous deployment, the release proceeds automatically if the defined conditions pass. Either approach should verify the result after deployment and preserve a way to stop further rollout.
Suppose the new release starts returning empty estimates for a particular destination. The pipeline being green does not negate that problem. The team can pause rollout, disable the feature if that option exists, or restore a previous compatible artifact while investigating the missing test case.
Build recovery and security into the workflow
Why: Automation can repeat unsafe actions just as efficiently as safe ones. A pipeline often holds credentials and permissions that make it an attractive route into production.
How: Separate permissions by stage and environment. Untrusted code contributions should not automatically receive production secrets or privileged execution. Use supported credential storage, minimize long-lived access, and review external actions or plugins before granting them authority.
Preserve logs and artifact metadata needed to identify what ran, under which configuration, and with whose authorization. Avoid putting tokens, private data, or complete sensitive payloads in build output. Logs should support investigation without becoming another source of exposure.
Plan rollback carefully. Restoring an older application may be straightforward, but a destructive schema change or an external transaction may not be reversible. Compatible migrations, staged data changes, and explicit repair procedures can be necessary. “Redeploy the old version” is not a complete recovery plan for every release.
Monitor outcomes after deployment. Google's service-level objectives chapter explains choosing indicators that represent service behavior. Use appropriate signals such as successful requests and latency to assess the release, rather than treating a healthy deployment job as proof of a healthy service.
Start with one service and a minimal pipeline. Add stages when they address a documented failure or risk. A small, reliable pipeline is more useful than an elaborate workflow that nobody understands or can repair.
Questions About CI/CD Pipelines
Does a pipeline replace code review?
No. Automation checks what it has been configured to check. Review can examine intent, architecture, maintainability, and risks that tests do not capture. The balance depends on the change and team, but a passing pipeline should be treated as evidence for review rather than a universal replacement for it.
Can CI/CD work for a monolithic application?
Yes. The practices do not require microservices, containers, or a particular cloud. A monolith can benefit from repeatable builds, automated testing, and controlled deployment. Large applications may need careful test organization and release boundaries, but architecture alone does not rule out CI/CD.
Must every merge reach production immediately?
No. Continuous integration does not require automatic production release. Continuous delivery allows an approval or scheduling decision after validation. Even with continuous deployment, teams define which branches, repositories, and change types qualify for the automated path.
What should happen when the main pipeline fails?
Make the failure visible, identify an owner, and avoid adding unrelated changes that make diagnosis harder. Depending on the cause, fix the defect or revert the change. Investigate infrastructure and flaky-test failures too; repeatedly ignoring failures undermines the value of the shared signal.
Automate Delivery With Useful Checks
CI/CD makes software delivery more repeatable by connecting small code changes to automated evidence and controlled releases. Start with reliable checks and traceable artifacts, then add deployment automation at the pace your testing, monitoring, and recovery practices can support.
Next steps: Compare DevOps tools, prepare observability for production, or explore the DevOps hub.
Sources
- GitHub — Understanding GitHub Actions
- Google — Release Engineering
- Google — Service Level Objectives
This guide is general education, not professional advice.