CI/CD Pipeline Stages Explained: Build, Test, Security Scan, Deploy, and Rollback

Overview

If your team ships cloud-native applications, the pipeline is where engineering standards become real. Code quality, deployment safety, security controls, and release speed all meet here. That is why it helps to think about CI/CD pipeline stages as a sequence of decisions, not just a sequence of jobs.

At a high level, a modern build test deploy pipeline usually answers five questions:

• Can we build it? The application compiles, packages, and produces deployable artifacts.
• Does it work? Automated tests verify expected behavior at multiple levels.
• Is it safe to ship? Security, policy, and compliance checks catch common risks before release.
• Can we release it predictably? The deploy stage promotes a known artifact through environments with controlled configuration.
• Can we recover quickly? A rollback path reduces the impact of bad releases or broken infrastructure changes.

Those questions sound simple, but many pipelines break down because teams mix responsibilities or skip transitions between stages. For example, a test suite may assume local defaults while deployment uses cloud-managed services; a security scan may run only after merge; rollback may exist in theory but fail when a database migration is irreversible.

A healthier approach is to design the pipeline as an explicit workflow with inputs, outputs, and exit criteria. In practice, that means each stage should define:

• What it receives
• What it validates
• What artifact or signal it produces
• Who owns failures at that point
• Whether the stage blocks promotion

That framing makes the pipeline easier to evolve as your tooling changes. Whether you use GitHub Actions, GitLab CI, Jenkins, Azure DevOps, CircleCI, or a platform-specific system, the stages remain recognizable. Tools change; workflow principles stay useful.

Step-by-step workflow

This section breaks down the most common devops workflow stages and shows how they fit together in a practical release path.

1. Source and trigger

Every pipeline starts with an event. That may be a pull request, a merge to the main branch, a version tag, or a manual approval for production. The important thing is to separate pipeline behavior by trigger type.

A simple pattern looks like this:

• Pull request pipeline: fast feedback only; build, lint, unit tests, and lightweight scanning
• Main branch pipeline: full verification; packaging, integration tests, artifact creation
• Release pipeline: environment promotion, deployment checks, and approvals where needed

This separation helps control cost and runtime while keeping important gates in place. Not every code change needs a full production-like deployment during review, but every release should come from a verified artifact.

2. Build stage

The build stage turns source code into something deployable and reproducible. Depending on your stack, that may be a container image, compiled binary, static frontend bundle, serverless package, or versioned library.

The build stage should usually do the following:

• Install dependencies in a repeatable way
• Compile or transpile code
• Run formatting or lint checks if they are fast enough to fail early
• Package the application into a deployable artifact
• Stamp the artifact with version metadata such as commit SHA, build number, and creation time

Two details matter here. First, builds should be deterministic enough that the same commit produces the same kind of artifact. Second, you should promote the artifact that passed validation rather than rebuild differently for each environment. Rebuilding during deployment introduces drift.

For containerized applications, it also helps to keep build context small, pin base images where appropriate, and separate dependency layers from application code to improve cache efficiency.

3. Test stage

Testing is usually not one stage in practice. It is a set of checks with different speed, confidence, and ownership. The common mistake is to treat all tests as equal and run them in the wrong order.

A more practical sequence is:

• Static checks: linting, type checks, schema validation
• Unit tests: fast verification of business logic
• Integration tests: application behavior against databases, queues, caches, or third-party interfaces
• Contract tests: API compatibility between services and clients
• End-to-end tests: critical user journeys only, not every permutation

The goal is not maximum test count. The goal is fast detection of meaningful failure. Put cheap, high-signal checks first. Reserve slower and more brittle tests for code that is already likely to pass.

For enterprise web app development, integration tests often provide more value than a large set of UI tests, especially where service boundaries, authentication flows, and database behavior create real release risk. If your application exposes APIs, contract validation can be especially valuable when coordinating teams. Related decisions around API styles are covered in OpenAPI vs GraphQL vs gRPC: Choosing the Right API Style for Internal and External Platforms.

4. Security scan stage

Security scan in CI/CD should be part of normal delivery, not a separate event that arrives too late. The scope will vary by organization, but useful scanning commonly includes:

• Dependency vulnerability scanning
• Container image scanning
• Static application security testing
• Secret detection
• Infrastructure-as-code policy checks
• License or package policy checks where relevant

The main design question is not whether to scan. It is how to gate intelligently. If every low-severity finding blocks every build, teams will quickly learn to ignore the system. A better approach is to define blocking rules based on exploitability, package reachability, severity, environment, and available remediation path.

For example, a pull request may fail on exposed secrets or critical issues in newly introduced dependencies, while lower-priority findings are recorded for follow-up. Production promotion may require a stricter policy than development deployment.

Security checks should also match the app’s real behavior. If your release includes auth changes, token handling, or browser-to-API flows, testing around session patterns, OAuth flows, and CORS behavior should not be left to chance. Related references include Bearer Token vs Session Cookie: Which Auth Pattern Fits Your Enterprise Web App?, OAuth 2.0 Grant Types Comparison for Web Apps, SPAs, APIs, and Machine-to-Machine Services, and CORS Errors in Production: A Debugging Checklist for APIs, Browsers, and Reverse Proxies.

5. Artifact publish and promotion

Once code has passed build, test, and scanning, the resulting artifact should be stored in a registry or package repository. This is the handoff point between continuous integration and continuous delivery.

The artifact should be:

• Versioned
• Immutable
• Traceable to source and pipeline run
• Associated with test and scan results

Promotion then becomes a matter of moving the same artifact through environments with different configuration, credentials, traffic routing, and approvals. This makes incident review easier because you know what actually changed: the artifact, the environment configuration, or both.

6. Deploy stage

The deploy stage releases a known artifact to a target environment. This is where many teams realize that deployment is not one action but a series of controlled transitions:

• Prepare infrastructure or runtime targets
• Apply configuration and secrets
• Run database or schema changes where needed
• Shift traffic or activate the new version
• Verify service health

For cloud-native systems, deployment strategy matters as much as deployment automation. A rolling update may be fine for stateless services. Blue-green or canary approaches may be safer for user-facing systems or riskier changes. If you need a structured comparison, see Blue-Green vs Canary vs Rolling Deployments: Which Release Strategy Should You Use?.

Database changes deserve special care because they can make rollback hard. Backward-compatible migrations, expand-and-contract patterns, and explicit migration gates can reduce release risk. A useful companion reference is Database Migration Checklist for Zero-Downtime Deployments.

7. Post-deploy verification

Deployment is not complete when the tool reports success. It is complete when the system behaves acceptably in the target environment. Post-deploy verification commonly includes:

• Health checks and readiness checks
• Smoke tests for critical endpoints
• Synthetic checks for login, checkout, or other business-critical journeys
• Error rate, latency, and saturation monitoring
• Log inspection for deployment-specific failures

This stage should be fast enough to inform release decisions while still catching real issues. A short set of high-value checks beats a long, fragile script nobody trusts.

8. Rollback stage

The rollback stage pipeline is often described but rarely rehearsed. That is a problem because rollback is not just “deploy the previous version.” Real rollback depends on what changed:

• Application code only: often straightforward if previous artifacts remain available
• Configuration change: rollback may require restoring flags, secrets, or environment settings
• Database migration: may require forward fixes instead of reversal
• External dependency behavior: rollback may not help if a provider or integration changed

That is why good rollback design starts before deployment. Teams should decide:

• What events trigger rollback automatically versus manually
• Who can approve rollback
• How traffic is shifted back
• Whether feature flags can disable risky functionality faster than a full redeploy
• How data compatibility is preserved between versions

In mature pipelines, rollback is paired with incident capture. Every failed release should leave behind evidence: the exact artifact, logs, metrics, test results, and reason for reversal. That information is what improves the next version of the pipeline.

Tools and handoffs

The best pipeline tools are the ones that keep handoffs explicit. A common cause of delivery friction is not the choice of CI platform but the lack of shared expectations between developers, DevOps, security, and operations.

Here is a practical way to assign ownership by stage:

• Developers: build scripts, test definitions, service-level deployment requirements, health checks
• Platform or DevOps teams: CI runners, artifact registries, environment automation, secrets integration, deployment orchestration
• Security teams: scan policies, exception handling, blocking thresholds, audit requirements
• Operations or SRE teams: observability standards, rollback criteria, incident response guardrails

Useful handoffs usually include these artifacts and signals:

• Source commit and pull request context
• Build artifact and version metadata
• Test reports with pass/fail details
• Scan reports with gating outcomes
• Deployment manifests or release definitions
• Post-deploy verification results

For service-based applications, handoffs also include API expectations and operational behaviors. If your release affects webhooks, idempotency, status handling, or rate limiting, pipeline verification should reflect that. Related operational references include Webhook Debugging Checklist: Retries, Signatures, Ordering, Timeouts, and Replay Protection, Idempotency Keys Explained: Preventing Duplicate API Requests in Payments, Forms, and Job Queues, API Rate Limiting Strategies Compared: Token Bucket, Leaky Bucket, Sliding Window, and Fixed Window, and HTTP Status Codes for API Debugging.

One practical benchmark for pipeline design is whether a new engineer can answer three questions quickly:

1. What stages run for a pull request, a merge, and a production release?
2. What blocks promotion at each stage?
3. What is the exact recovery path if production verification fails?

If those answers are spread across chat history and tribal knowledge, the pipeline is carrying hidden operational risk.

Quality checks

To improve a pipeline over time, teams need quality checks that go beyond “the jobs passed.” A useful CI/CD benchmark includes both technical and workflow signals.

Pipeline quality checklist

• Build reproducibility: the same commit produces a consistent artifact
• Fast feedback: pull request checks return quickly enough to influence developer behavior
• Layered testing: cheap tests run before expensive ones
• Meaningful security gating: blocking rules are strict where needed and realistic in practice
• Artifact immutability: deployment uses a previously verified artifact, not a fresh rebuild
• Environment parity: test and production differ intentionally, not accidentally
• Observable deploys: every release is visible in logs, metrics, and traces
• Rollback readiness: reversal is documented, permissioned, and tested
• Low manual drift: emergency fixes do not bypass the pipeline without traceability

Common failure patterns

Many pipeline problems repeat across stacks:

• Tests rely on unstable shared environments
• Security findings are too noisy to act on
• Deployments include both app changes and risky database changes without staged verification
• Rollback is impossible because schema changes are not backward compatible
• Production approvals exist, but no one knows what they are approving
• Post-deploy checks are too shallow to catch user-facing failures

If your team is seeing these patterns, the fix is rarely “add more tools.” It is usually to tighten stage boundaries, reduce ambiguity, and define clearer exit criteria.

A practical benchmark for improvement

If you want a simple maturity path, improve in this order:

1. Make builds repeatable and artifacts traceable
2. Separate pull request, merge, and release pipelines
3. Order tests by speed and signal
4. Integrate security scans with realistic blocking rules
5. Standardize deployment and post-deploy checks
6. Rehearse rollback, especially around data changes

This sequence tends to produce better delivery outcomes than trying to optimize everything at once.

When to revisit

Your pipeline should be treated as a maintained system, not a one-time setup. Revisit it whenever the underlying delivery assumptions change.

Useful triggers include:

• You adopt a new runtime, framework, or packaging model
• You move from a monolith to services, or consolidate services back into a larger application
• You introduce new compliance or security requirements
• Your release frequency changes significantly
• Your deployment strategy changes from rolling to canary or blue-green
• Your application starts depending more heavily on queues, webhooks, third-party APIs, or background workers
• Your mean time to recover after failed releases is still too high

A practical review cadence is to inspect the pipeline after major incidents, after platform migrations, and at regular intervals when tools or platform features change. The goal is not to redesign everything each time. The goal is to ask whether the current stages still match the real risks of your software delivery process.

To make that review useful, end with an action list:

1. Map your current stages from code commit to rollback.
2. Write the input, output, and blocking rule for each stage.
3. Identify where artifacts are rebuilt or where manual steps create drift.
4. List the top three release failure modes from the past quarter or year.
5. Add or refine one stage that would have reduced those failures.
6. Test the rollback path for the next high-risk release, especially if it includes a schema change.

If you do only that, your CI/CD workflow will become easier to reason about, safer to operate, and simpler to improve as your stack evolves. That is the real value of understanding ci cd pipeline stages: not memorizing a fixed diagram, but building a delivery system your team can trust.