Build a CI/CD pipeline that is safe to release

CI and CD are a controlled path for changes

Continuous integration gives a team fast, repeatable evidence about a proposed change. Continuous delivery prepares a releasable artifact and moves it through controlled environments; continuous deployment goes further by releasing eligible changes automatically. Teams can use different release policies, but the goal is the same: make a change traceable from source revision to production behavior.

A pipeline is more than a sequence of shell commands. It is a set of trust boundaries: who can change the workflow, what code executes, which credentials it receives, what artifact is produced, and what evidence is required before a production effect.

• Trigger focused validation for pull requests and relevant branches
• Build, test, scan, and publish an identifiable artifact
• Promote through test and production environments with appropriate protection
• Record release provenance, deployment results, and recovery actions

Build once, then promote the same artifact

If staging tests one build and production rebuilds from source, the production release is not the artifact that passed staging. Build the application or package once, assign it an immutable version or digest, and promote that exact output. Keep environment configuration separate and make each deployed version discoverable from logs or a release record.

Treat pipeline output as a supply-chain asset. Restrict who can publish or replace artifacts, preserve test and scan evidence, and avoid mutable tags as the only proof of identity. For infrastructure changes, retain the reviewed plan or equivalent change record alongside its source revision and target environment.

• Tie artifact identity to a commit and build run
• Do not silently rebuild during promotion
• Keep environment-specific values outside the artifact
• Make provenance and deployment history available during incident response

Place fast, deterministic checks early

Run formatting, lint, type checks, unit tests, and configuration validation before expensive integration or deployment stages. Add integration and contract tests where components meet, then run security and policy checks that match the system's risk. A green build is evidence only for the checks it actually ran, so name the important gaps rather than implying the pipeline proves correctness.

For AI workloads, include evaluation assets and configuration in version control. A release may need checks for prompt or schema contracts, retrieval quality, tool permissions, and safety behavior, in addition to ordinary software tests. Keep evaluation data representative and approved for use.

• Fail quickly on deterministic errors
• Run integration tests against controlled dependencies
• Use representative quality and security checks before promotion
• Keep the same acceptance criteria across candidate releases

Protect the deployment boundary

Give build jobs only the permissions they need, and separate them from jobs that can change production. Prefer short-lived identity federation where the platform supports it instead of long-lived cloud secrets. Protect sensitive environments with branch restrictions, reviewers, and other checks appropriate to the impact of the change.

Review workflow changes as executable code. Limit third-party actions or tasks to trusted, pinned versions where supported, avoid exposing deployment credentials to untrusted pull-request code, and log enough context to investigate without copying secrets or sensitive data into job output.

• Separate build, test, and production identities
• Use least privilege and short-lived credentials
• Require approval for high-impact production changes, not every low-risk step
• Keep secrets out of logs, artifacts, and pull-request execution contexts

Deploy gradually and recover deliberately

Before broad rollout, verify the deployed version with smoke tests and health signals tied to user impact. Use progressive exposure, feature flags, or a staged rollout when the workload warrants them. Set explicit stop conditions such as error rate, latency, data quality, or task-success regressions.

A rollback is not always a safe inverse: database migrations, external side effects, and data writes may be irreversible. Define whether recovery means rollback, roll-forward, disablement, or degraded operation. Practice the chosen path and record who makes the decision.

• Check health after deployment, not just job completion
• Use backward-compatible migrations where possible
• Keep a known-good artifact and configuration available
• Measure time to detect and restore service during exercises

A practical pipeline design exercise

Choose one service and draw its path from a pull request to production. For every stage, write its trigger, inputs, permissions, output, failure behavior, and owner. Then identify one change that must stop at a human approval and one failure that should trigger an automatic halt. This gives you a useful design review before writing platform-specific YAML.

Choose your next step

Use the roadmap as a loop, not a reading list. Pick the next action that produces evidence.

Frequently asked questions