The key takeaway
Start with one representative service and promote the same versioned artifact through staging and production. Run tests, static checks and the build on each proposed change, scope credentials tightly and let failed checks block promotion. Agree the recovery plan before release, because rollback does not automatically reverse database migrations.
Where should you start when setting up a CI/CD pipeline?
Start with a representative service rather than automating every repository at once. Define the artifact to build, the target environment and the person responsible for the release.
Use the same versioned artifact through staging and production. Rebuilding different artifacts in each environment makes it harder to reason about what was validated.
What should a CI/CD pipeline check before deployment?
On a proposed change, run dependency installation from the lockfile, relevant tests, static checks and the production build. Add security checks that have clear ownership and a response process.
Keep credentials out of source and logs. Scope CI permissions to the job, environment and resources needed; prefer short-lived deployment credentials where supported. For infrastructure changes, see GitOps with Terraform release guardrails.
An illustrative pipeline sequence
For this repository the local checks are npm test, npm run lint and npm run build. These are example validation steps, not an executable deployment configuration for every stack.
A release job should fetch the approved artifact, verify the target environment, deploy to a lower-risk target, run smoke checks, then request or enforce the agreed production promotion decision. Capture the artifact version and approvals in the release record. To separate that release decision from deployment, see feature flags for safer production releases.
Make failure handling part of the pipeline
A failed check blocks promotion and preserves diagnostic output without secrets. A failed rollout should leave the last known usable version available where the architecture permits it.
Define the recovery decision before release. Application rollback does not automatically reverse database migrations or external side effects; rehearse the specific recovery plan.
How do you keep a CI/CD pipeline maintainable?
Protect production permissions, review environment changes and retain the evidence needed for your own operating and assurance requirements. Do not claim a universal audit pass from pipeline tooling alone. For an example of collecting that evidence continuously, see our continuous controls monitoring case study.
Track change failure, release lead time and user-facing reliability with SLOs and error budgets. Add complexity only when a real failure mode or control requirement justifies it.
Discuss the next decision
If you need help with the decision, explore the relevant engineering engagement or email us about your scope and constraints. Outputs and delivery commitments are agreed per project.
Questions and answers
Does every deployment need manual approval?
The approval model depends on risk and controls. Agree it explicitly; automate repeatable checks without removing accountable ownership.
What should happen when smoke tests fail?
Stop promotion, preserve evidence and follow the agreed recovery plan. Do not mark a release successful merely because a deployment command exited cleanly.