CI CD Pipeline: 10 Stages for Safer Software Releases
A CI CD pipeline is an automated path that takes a software change from source control through validation and toward release. Continuous integration (CI) helps teams merge and test changes frequently. Continuous delivery or deployment (CD) automates later steps so a validated change can be released in a controlled way. Together, these practices shorten feedback cycles and make releases more repeatable.
This article explains the main pipeline stages, how to introduce quality and security checks, and what to measure so automation improves reliability instead of simply moving risk faster.
What happens in a CI CD pipeline?
A developer commits a change to a shared repository. The pipeline then builds the software, runs automated checks, packages the result, and deploys it to one or more environments. A delivery pipeline can stop before production for an approval, while continuous deployment releases qualifying changes automatically after they pass the required checks.
The precise distinction between continuous delivery and continuous deployment matters to some teams, but the goal is broader: keep software in a state that can be released safely. Google Cloud’s DevOps capabilities guidance describes continuous delivery as making deployment reliable and low risk, and its CI/CD reference architecture shows how build, artifact, and deployment components can work together.
10 stages to consider
- Source control trigger. Start a run when a developer opens a change, merges code, or creates a release tag. Use branch rules to define which changes can reach protected branches.
- Dependency and configuration checks. Confirm package versions, configuration syntax, and required files. Lock dependencies so the same source revision does not unexpectedly pull a different package later.
- Build. Compile the application or create a deployable package. Make build outputs traceable to the source commit and environment.
- Fast automated tests. Run unit tests and static checks early so developers receive quick feedback while a change is still easy to fix.
- Security and quality scans. Check dependencies, source code, secrets, and container images. Treat findings according to severity and context, rather than ignoring alerts or blocking every low-risk item without review.
- Package and store artifacts. Create an immutable artifact and record its version, source, and build metadata. Promote the same artifact through later environments where possible.
- Deploy to a test environment. Apply environment-specific configuration and verify that the package starts and can reach necessary dependencies.
- Integration and acceptance checks. Test interactions across services, data stores, and user workflows. Keep slow end-to-end tests targeted so they add signal without making feedback needlessly slow.
- Production release. Use a rollout strategy such as a canary, phased release, or traffic switch. For higher-risk changes, require a human approval step.
- Observe and recover. Watch errors, latency, business metrics, and infrastructure health. Define how to pause, roll back, or disable a faulty release.
How to design a reliable pipeline
Keep feedback fast and useful
Run the shortest, most informative checks first. If a small unit test fails, the developer should learn that before waiting for a full deployment. Group test stages by what they tell the team, not merely by which tool runs them. A readable result should identify the failed check and point to the log or test case.
Build once and promote the same artifact
Build the application once for a source revision, then promote that artifact from testing toward production. Rebuilding separately for each environment can create differences that make a tested version unlike the live version. Keep secrets and environment settings outside the artifact, with access controlled separately.
Make environments as similar as practical
Development, testing, and production rarely match perfectly, but configuration differences should be visible and intentional. Use version-controlled configuration and infrastructure definitions so the team can review how each environment differs.
Protect credentials and production access
Store pipeline credentials in a secrets manager, limit their scope, and rotate them. Give the pipeline only the permissions needed for a stage. Separate the authority to approve a release from the credentials that perform the deployment when the risk warrants it.
Support staged rollout and rollback
A deployment is not safe merely because it completed. Gradual rollout can limit exposure while monitoring catches problems. Decide in advance which signals pause a release and how the team will return to a known-good state or disable a feature. Database changes may require a forward-compatible migration plan rather than a simple code rollback.
Continuous delivery versus continuous deployment
With continuous delivery, the pipeline keeps each successful change ready for release, but a person or policy decision may trigger production deployment. With continuous deployment, every change that passes the pipeline can proceed to production automatically. A team can choose different approaches for different services or risk levels.
Automation does not remove accountability. If the team lacks reliable tests, useful alerts, or a recovery plan, automatic release can increase the speed of mistakes. Begin by automating repeatable validation and deployment preparation. Increase release automation as the checks and operational response improve.
What to measure
Measure the pipeline and the software delivery outcome. Useful signals include time from change to feedback, build success rate, deployment frequency, change failure rate, recovery time, and the duration of blocked releases. These measures help identify bottlenecks, but should not become targets that encourage teams to ship low-quality changes.
Also track test flakiness, time spent waiting for environments, security findings by severity, and rollback frequency. Review trends alongside product quality and user impact. A metric should help the team learn where the process needs work, not rank individual developers.
Common CI CD mistakes
- Turning every check into a release blocker. Prioritize checks by risk and keep noisy alerts from eroding trust.
- Relying only on end-to-end tests. Add faster unit and integration checks to isolate failures and shorten feedback.
- Using mutable artifacts. Tag and trace packages so the team knows exactly what it deployed.
- Keeping secrets in scripts. Use protected secret storage and limit permissions.
- Skipping post-deployment observation. Verify outcomes after release and define who responds to alerts.
- Automating an unclear process. Clarify ownership, environments, approvals, and rollback before scripting every step.
When teams need to modernize an existing delivery process, a documented application lifecycle management workflow can help connect planning, development, testing, and release decisions.
How to introduce a CI CD pipeline
- Map the current path from a code change to production.
- Identify the most common delays and preventable failures.
- Automate build and fast tests for one service or application.
- Add artifact traceability, security checks, and a safe test deployment.
- Define production approvals, rollout signals, and recovery steps.
- Review incidents and user outcomes, then improve one bottleneck at a time.
Start with the workflow that provides the clearest value. A pipeline does not have to cover every tool or environment on day one. A small, reliable foundation that teams trust is more useful than an elaborate process whose checks are often bypassed.
Example: a release from commit to production
A small web application might run formatting and unit tests after each pull request. After approval, the pipeline builds an immutable container image, scans dependencies, and deploys it to a test environment. Integration tests verify the database and payment sandbox. A release candidate then moves to production through a canary rollout. The team watches error rates and business transactions before increasing traffic.
This flow makes each step visible. If the build fails, developers see a commit-level error. If the canary causes a rise in failed checkouts, the rollout can pause before all customers receive the change. The exact stages vary by application, but the pipeline should explain what evidence allows a change to progress.
Security belongs throughout the pipeline
Use short-lived or narrowly scoped credentials where supported. Separate build permissions from production deployment permissions, protect repository secrets, and restrict who can edit workflows that control a release. Scan dependencies and artifacts, but also set a process for triaging findings so teams do not normalize ignored alerts.
Keep deployment logs useful without exposing secrets or personal data. Record the artifact digest, source commit, environment, and approval record. This traceability helps incident responders connect a production change to the code and configuration that produced it.
Balance confidence and speed
A long pipeline can create pressure to bypass checks. Review which tests find unique defects and which duplicate existing coverage. Run stable, fast tests early, then reserve slower end-to-end checks for a smaller number of high-value paths. Fix flaky tests quickly because unreliable feedback weakens confidence in the entire process.
Pair release automation with operational ownership. Define who receives alerts, what signals trigger rollback, and how teams communicate during an incident. A staged release without a person watching the result is not a complete safety strategy.
For teams reworking an existing delivery process, application lifecycle management can provide a broader view of how planning, testing, release, and maintenance connect.
Choose a deployment strategy for the application
A rolling deployment replaces instances gradually and can work well when the old and new versions can operate at the same time. A canary sends a limited share of traffic to the new version and compares service health. A blue-green deployment keeps two environments available and switches traffic after validation. Each strategy has different infrastructure needs and failure modes, so test it with the application’s database, sessions, background jobs, and external integrations.
Define success signals before rollout. Error rates, latency, and resource saturation help reveal technical trouble; business measures such as completed checkouts or accepted submissions show whether users can finish the task. Avoid using a single signal that might stay green while a critical workflow fails.
Keep database changes compatible
Database schema updates often make rollback more complicated. A safer pattern is to make a change that old and new application versions can both tolerate, deploy the application, migrate data, and remove the old structure in a later release. Test long-running migrations and backups separately from code deployment.
Document recovery steps and practice them. A rollback button is only useful if the team knows which data changes can be reversed and what to do when a migration has already modified production records. Include on-call ownership and a way to pause a pipeline when an upstream dependency is unhealthy.
Frequently Asked Questions
What is the difference between CI and CD?
CI automatically integrates and checks code changes. CD extends automation toward release, either keeping changes ready for a release decision or deploying them automatically after they pass required checks.
Does a CI CD pipeline deploy every change to production?
No. Continuous delivery often includes an approval or release decision. Continuous deployment can automatically release passing changes, but the choice depends on testing maturity and business risk.
Which tests should run first?
Run fast checks that catch common errors early, such as formatting, static analysis, and unit tests. Follow with broader integration, acceptance, and deployment checks.
How can a team make a pipeline safer?
Use traceable artifacts, scoped credentials, reliable automated checks, staged rollout, production monitoring, and a tested recovery plan.
Conclusion
A CI CD pipeline creates a repeatable route from code change to release. Build it around fast feedback, trustworthy checks, secure access, traceable artifacts, and safe recovery. Improve it from real delivery data, and let the level of automation grow with the team’s ability to validate and operate each release.
