CI/CD Fundamentals · Module 12 of 12

Capstone: build, test, package, promote and rollback

Combine source identity, quality gates, immutable artifacts, staging verification, controlled promotion and rollback into one auditable delivery flow.

Learning objectives

By the end of this module, you should be able to:

Run a complete local CI/CD pipeline from source to simulated production.
Promote one validated artifact rather than rebuilding.
Demonstrate deterministic rollback to the previous release.

The capstone preserves evidence between stages

The source identifier, test result, artifact checksum and deployed release identity should agree. Each stage consumes the output of the previous stage rather than silently recreating it.

Promotion changes deployment state, not artifact content

The staging artifact is the production candidate. Promotion copies or references the same artifact identity after validation.

Rollback is part of delivery design

A production pipeline is incomplete if it can deploy forward but cannot identify and restore a known-good previous version.

Worked examples

See the idea in practice.

Evidence chain

source-id -> tests PASS -> artifact + sha256 -> staging health PASS -> production -> release record

Every arrow should be explainable after the fact.
The same artifact identity is retained through staging and production.

Hands-on lab

Lab — End-to-end CI/CD capstone

Goal: Build one immutable artifact, validate it in staging, promote it to production and exercise rollback.

STEP 1

Create source and tests

mkdir -p ~/gnu-cicd-labs/module12/{src,artifacts,staging,production,releases} && cd ~/gnu-cicd-labs/module12
printf 'status=healthy\nmessage=GNU-CICD\n' > src/app.conf
grep -q 'status=healthy' src/app.conf

STEP 2

Create source identity and artifact

SOURCE_ID=$(sha256sum src/app.conf | awk '{print $1}')
printf '%s\n' "$SOURCE_ID" > source.id
tar -czf artifacts/app-${SOURCE_ID:0:12}.tgz src source.id
sha256sum artifacts/app-*.tgz > artifacts/SHA256SUMS

STEP 3

Validate and deploy staging

(cd artifacts && sha256sum -c SHA256SUMS)
cp artifacts/app-*.tgz staging/
tar -xzf staging/app-*.tgz -C staging
grep -q 'status=healthy' staging/src/app.conf

STEP 4

Promote exact artifact

ARTIFACT=$(basename artifacts/app-*.tgz)
cp "artifacts/$ARTIFACT" production/
printf '%s\n' "$ARTIFACT" > production/release.txt
cp production/release.txt releases/last-known-good.txt

STEP 5

Exercise rollback record

printf 'app-bad.tgz\n' > production/release.txt
cp releases/last-known-good.txt production/release.txt
cmp production/release.txt releases/last-known-good.txt

Verify

The artifact checksum passes.
Staging health passes before production promotion.
Production release.txt returns to the recorded known-good artifact after rollback simulation.

Expected outcome

A complete auditable delivery flow exists without rebuilding between staging and production.

If it fails

If more than one artifact exists, clean the disposable lab directory before rerunning to avoid wildcard ambiguity.
A real production pipeline should use deployment-system health and rollback primitives rather than filesystem copies.

Real-world connection

The capstone mirrors the core control flow behind a production GitHub Actions pipeline while remaining locally testable and credential-free.

Avoid these traps

Common mistakes

Rebuilding after staging validation.
Promoting before health verification.
Overwriting the previous release identity before the new release is proven healthy.

Knowledge check

Can you explain it without looking back?

Open each answer only after you have tried to answer the question yourself.

1What must remain the same from staging validation to production promotion?

The immutable artifact identity/bytes.

2What evidence should be recorded for rollback?

The previous known-good immutable release identity.

3Why is the capstone credential-free?

It validates CI/CD mechanics locally; hosted-service authentication can be practiced separately without putting secrets into training scripts.

My Learning

Record your progress for this module.

Progress is saved in this browser immediately. When you sign in to My Learning, it can also sync across devices.

Not started

Core lab attemptedRecord this after meaningfully completing or attempting the module's core lab.Knowledge checks attemptedThis is marked automatically after you open every answer in the module; you can also record it manually.

Attempt the core lab and knowledge checks before marking the module complete.