CI/CD Pipeline Architecture

A release is a traceable artifact and a reversible decision

Continuous integration checks changes as they merge. Continuous delivery keeps a tested release ready for deployment; continuous deployment automatically promotes qualifying changes. Tests reduce risk but do not prove every production behavior correct.

Build once, identify precisely

A useful pipeline records the source revision, dependency lockfile, build environment and artifact digest. Promote the same artifact through testing and production. A mutable tag such as stable can point to a different image later; record the digest that was actually tested.

Separate stages also need explicit file transfer. In a hosted workflow, a new job does not automatically inherit a previous job’s checkout, binaries, container login or cluster credentials. Use a registry or artifact service and verify what the deployment stage consumes.

Worked release: add a profile field

Suppose version A reads name, while version B should use display_name. Renaming the database column before the rollout makes A fail, including any A instance retained for rollback.

Use an expand-and-contract sequence:

1. Add the new nullable field while A remains compatible.
2. Deploy code that tolerates either field and defines how concurrent updates are copied.
3. Backfill in bounded batches; verify missing or conflicting rows.
4. Move readers to the new field and observe production behavior.
5. Remove the old path only after the rollback window closes and all consumers have migrated.

A traffic rollback restores application code, not the previous database state. If B wrote an incompatible event, switching back to A cannot make that event understandable. Test mixed-version readers, not just a clean installation.

Choose the rollout for the failure cost

Kubernetes Deployments document rolling-update controls such as surge and unavailable replicas. Extra surge capacity is real resource usage; rolling updates are not automatically free of overhead or downtime.

Make checks answer a failure question

A syntax or type check finds malformed code. A migration test checks compatibility with existing records. A request-level test checks the published artifact’s actual response. A rollback rehearsal verifies that the previous artifact can still serve current data. Give each check an owner and a failure action.

For a hypothetical 1% canary, an error rate of 2/20 requests is too little evidence to compare confidently with a stable fleet serving thousands. Set an observation period and sample requirement, and inspect important endpoints separately. Stop on correctness failures even when an aggregate metric looks acceptable.

Protect deployment authority

Keep build jobs from receiving production privileges they do not need. Separate untrusted contribution checks from jobs that can publish artifacts or modify infrastructure. Use narrowly scoped credentials, pin third-party actions to reviewed revisions and avoid printing secrets. See GitHub’s secrets guidance for workflow-specific handling.

A release record you can use

Record the artifact digest, approved migration sequence, traffic switch time, observation window and rollback limitations. During an incident, these facts let you answer whether reverting is safe. “All tests passed” alone does not explain what changed or which state can be recovered.

Read blue-green deployment for a cutover example and distributed tracing for tracing a failing request across services.