Before looking at individual stages, it helps to see the pattern as a whole shape first.

Continuous integration versus continuous delivery

Continuous integration, often abbreviated CI, focuses narrowly on building and testing code every time it changes, catching integration problems early. Continuous delivery, or CD, extends that same idea all the way through to actually getting the software running somewhere real — staging, QA, and ultimately production — in a consistent, automated, and repeatable way.

Why a “standard” pattern is worth learning

While every organization’s exact pipeline differs in its details, an overwhelming majority converge on a broadly similar sequence of stages, because they’re all solving the same underlying problem: safely and reliably turning a code change into a working deployment. Learning this common pattern gives you a mental map that transfers easily to almost any real-world Jenkins pipeline you’ll encounter.

The rest of this tutorial explores each of these stages, and the ones that typically surround them, in far more depth.

This particular sequence isn’t arbitrary — it reflects hard-won lessons about the cheapest place to catch a given kind of problem.

The principle of catching problems as early as possible

Every stage in the standard pattern is ordered, in part, by a simple economic principle: the earlier a problem is caught in the sequence, the cheaper it is to fix. A compilation error caught in seconds during the build stage costs almost nothing; the same underlying mistake, if it somehow reached production instead, could cost hours of investigation and genuine damage to users.

Standardization as shared organizational knowledge

Because so many teams converge on a similar sequence, a new engineer joining any reasonably mature organization can often understand an unfamiliar pipeline’s overall shape almost immediately, simply because it follows the same broad pattern they’ve likely seen elsewhere — dramatically reducing onboarding time compared to a completely bespoke, unfamiliar structure.

A foundation, not a rigid rulebook

The standard pattern is best understood as a strong, well-tested starting point rather than a strict rule every team must follow identically — most real pipelines add, remove, or reorder specific stages to fit their own particular technology and risk profile, while still recognizably following this same overall shape.

Looking at the full sequence together shows how each stage builds confidence for the one that follows.

The core sequence, end to end

While details vary, the widely recognized core sequence runs from source retrieval, through building and testing, into packaging, and finally out through deployment to progressively more important environments — each stage assuming everything before it has already succeeded.

Confidence accumulating stage by stage

Each stage in the pattern exists to add a specific, distinct kind of confidence — the build stage confirms the code is structurally sound, the test stage confirms it behaves correctly, and deployment confirms it can actually run in a real environment. By the time an artifact reaches production, it has accumulated confidence from every earlier stage in the chain.

Where quality and security checks fit in

Static analysis, security scanning, and other quality checks typically sit alongside or shortly after the test stage, adding their own specific kind of confidence — about code quality and security posture — before the pipeline proceeds any further toward an actual deployment.

Understanding the mechanics behind stage execution clarifies exactly how the sequence is enforced.

Sequential execution and early exit

Jenkins runs a pipeline’s declared stages in the order they appear, and by default, if any stage fails, the pipeline stops immediately rather than continuing on to later stages — this is precisely the mechanism that enforces the “each stage assumes the previous one succeeded” principle described in the last chapter.

sequenceDiagram
    participant P as Pipeline
    participant Ck as Checkout
    participant B as Build
    participant T as Test
    participant D as Deploy
    P->>Ck: Run stage
    Ck-->>P: Success
    P->>B: Run stage
    B-->>P: Success
    P->>T: Run stage
    T-->>P: Failure
    P->>P: Stop pipeline, skip Deploy
        

What information carries forward between stages

As a pipeline moves from one stage to the next, the workspace — the shared folder holding checked-out source code and any files produced along the way, such as a compiled artifact — persists across stages within the same pipeline run, letting the test stage use exactly what the build stage produced, without needing to rebuild anything.

Post-build actions regardless of outcome

Beyond the main sequential stages, Jenkins pipelines typically include a separate post-build section that runs regardless of whether the pipeline succeeded or failed — commonly used for sending notifications or cleaning up temporary resources, ensuring these actions happen no matter how the pipeline concluded.

Following a single code change through the entire pattern shows exactly what data moves at each step.

What flows forward, and what stays behind

The core deployable artifact and its explicit version identifier flow all the way through the pattern, from build to final deployment, while intermediate details — raw compiler output, temporary test data — typically stay behind in the pipeline’s own logs and workspace, never needing to travel further than the stage that produced them.

Real-world pipelines adapt the standard pattern in a few recognizable ways, depending on their goals.

Choosing the right variation

The right variation for a given team depends heavily on their confidence in automated testing, their regulatory environment, and how costly a bad production deployment would actually be — the same risk-based reasoning that shapes promotion strategy elsewhere in this guide applies just as directly here.

Following a standard, well-understood pattern brings real benefits, but it isn’t automatically a perfect fit for every situation.

The risk of cargo-culting the pattern

Adopting every stage of the standard pattern simply because “that’s what everyone does,” without genuinely considering whether each stage adds real value for a specific team’s actual risk and needs, can result in a slow, heavy pipeline that adds friction without adding proportional safety.

Because this pattern is the path code takes all the way to production, security deserves attention at nearly every stage.

Security as a stage, not an afterthought

A mature standard pattern includes dedicated security checks — static analysis for known vulnerability patterns, dependency scanning for known-vulnerable libraries — as genuine stages in the sequence, rather than treating security as a separate, occasional activity disconnected from the everyday delivery process.

Protecting the pipeline itself, not just its output

Because this pattern touches source code, build tools, credentials, and deployment targets, the pipeline’s own infrastructure — the Jenkins controller, its agents, its credential store — is itself a meaningful attack surface, and securing it deserves the same seriousness given to the application code passing through it.

Approval gates as a security control

A manual approval gate before production, as discussed in Chapter 6, doubles as a security control — ensuring a specifically authorized human reviews and takes responsibility for each production release, which matters particularly in regulated or high-risk environments.

Because the standard pattern is used constantly, its overall health and speed deserve ongoing measurement.

Tracking the pattern’s overall health

A small set of well-known metrics, often referred to collectively as delivery performance metrics, capture how well an organization’s standard pipeline pattern is actually functioning as a whole, beyond any single build’s individual result.

graph LR
    A[Pipeline Runs] --> B[Lead Time Tracked]
    A --> C[Deployment Frequency Tracked]
    A --> D[Change Failure Rate Tracked]
    B --> E[Delivery Performance Dashboard]
    C --> E
    D --> E
    E --> F[Team Identifies Where to Improve]
        

Finding the true bottleneck

Measuring each stage’s individual duration separately, rather than only looking at total pipeline time, often reveals that the perceived bottleneck — commonly assumed to be the build stage — is actually somewhere less obvious, such as a slow, flaky end-to-end test suite or a long wait at a manual approval gate.

A handful of recurring design choices separate a standard pattern that stays fast and trusted from one that becomes a dreaded bottleneck.

Pattern: fail fast, expensive checks last

Well-designed pipelines order their stages so the fastest, cheapest checks — compilation, basic unit tests — run first, while slower, more expensive checks — extensive integration tests, full security scans — run later, ensuring an obviously broken change fails quickly without waiting through the pipeline’s most time-consuming stages first.

Anti-pattern: an overloaded, monolithic pipeline

Cramming every possible check and deployment target into one enormous, sequential pipeline, run identically for every single change regardless of its actual risk, makes even trivial changes take an unnecessarily long time to work through the entire sequence.

Pattern: parallelizing independent stages

Stages that don’t genuinely depend on each other’s output — for example, a linter and a unit test suite that both only need the built code — can often run in parallel rather than strictly one after another, meaningfully shortening the overall time the pipeline takes without weakening any of its individual checks.

These are the lessons most teams learn only after their pipeline has become slower or less trusted than it should be.

Common mistake: treating every stage as equally important to fix quickly

When a genuinely low-priority stage, such as an optional style check, starts failing frequently, teams sometimes treat it with the same urgency as a failing core test — better to explicitly distinguish which stages are truly blocking from which are advisory, so effort goes where it matters most.

Common mistake: letting the pipeline grow without periodic review

Stages get added over time to address specific past incidents, but are rarely removed even after they’ve stopped providing real value — periodically reviewing the full sequence and asking whether each stage still earns its place prevents the pipeline from slowly accumulating unnecessary weight.

Seeing how different kinds of organizations apply the standard pattern makes the concept concrete.

A common thread across all four examples

In each case, the organization has taken the same recognizable core sequence and tuned its exact weight, speed, and rigor to match its own specific needs — proving that the value of the standard pattern lies in its adaptable, well-understood shape, not in rigidly following one single, universal configuration.

Straightforward answers to the questions almost every newcomer to the standard CD pattern asks.

Continuous integration focuses on building and testing code changes, while continuous delivery extends that same automation all the way through to actually deploying the software to real environments, as explained in Chapter 1.

No — as discussed in Chapter 2 and Chapter 7, the standard pattern is a strong starting point meant to be adapted, not a rigid checklist every team must follow identically.

This is intentional default behavior, as covered in Chapter 4 — each stage generally assumes every earlier stage succeeded, so continuing past a failure would risk deploying something that hasn’t actually been verified.

Generally no — as discussed in Chapter 8, integrating security scanning as a genuine automated stage within the standard pattern catches issues far earlier and more consistently than treating it as a separate, occasional activity.

As covered in Chapter 10 and Chapter 11, ordering cheap checks before expensive ones and running genuinely independent stages in parallel are two of the most effective ways to shorten total pipeline time without sacrificing coverage.

Not necessarily — as discussed in Chapter 6 and Chapter 10, many teams run a lighter version of the pattern for feature branches and reserve the full sequence, including deployment stages, specifically for their main branch.

The standard CD pipeline pattern is a widely recognized, well-tested sequence — checkout, build, test, package, and deploy — that reflects decades of collective experience about the cheapest place to catch each kind of problem before it reaches production. Its value lies not in rigid, universal enforcement, but in providing every team a shared, adaptable vocabulary for safely and repeatedly turning a code change into a working deployment. A team that understands why each stage exists, and deliberately tunes the pattern’s exact weight and rigor to its own real risk profile, gets the full benefit of decades of accumulated best practice — while a team that blindly copies every stage without question risks building a slow, heavy pipeline that adds friction without adding proportional safety. The goal was never to follow the pattern exactly; it was always to deliver software safely, quickly, and consistently, and the pattern is simply the clearest, most proven path there.