Audit the path from commit to production: artifact identity, approvals, migrations, verification and recovery. Turn release risks into measurable fixes.
A green pipeline tells you that configured jobs passed. It does not prove that the intended artifact reached production, that database changes remain compatible, or that customers can complete their work. A CI/CD pipeline audit follows a real change from commit through deployment and recovery. Select a routine release and a recent failed release; comparing them reveals assumptions that a diagram alone will miss.
Follow the artifact, credentials and decision
Record the commit, build inputs, artifact digest, environment configuration and deployment identity. Check whether a tested artifact is promoted or rebuilt later with different dependencies. Establish who can change pipeline definitions, approve releases and access production credentials. A manual approval has limited value when its approver cannot see the version, risk or evidence being approved.
| Boundary | Evidence to request | Failure to investigate |
|---|---|---|
| Build | Dependency lockfile, build log and artifact identifier | Production cannot be linked to the reviewed commit |
| Deployment | Environment changes, migration sequence and release record | A partial rollout leaves incompatible versions running |
| Verification | Customer-journey checks and service signals | Infrastructure is healthy but checkout or login fails |
| Recovery | Rollback rehearsal and data recovery procedure | Old code cannot read the newly written data |
Rehearse the uncomfortable path
In a controlled environment, interrupt a deployment between stages. Verify that the pipeline reports the actual state and that an operator can safely resume or reverse the operation. Include schema migrations, background workers, scheduled jobs and feature flags. Rolling back an application image does not reverse database writes or actions already sent to external providers.
- Choose one release boundary and write its expected preconditions and postconditions.
- Run the normal path and preserve the artifact and deployment identifiers.
- Introduce a bounded failure, then follow the documented recovery steps.
- Record elapsed recovery, manual interventions and any unresolved data changes.
Fix the largest source of release uncertainty
Prioritise findings by customer impact and recoverability. An undocumented manual step that repeatedly blocks recovery may deserve attention before a slow but reliable test. Every repair ticket should name the boundary, evidence, owner and acceptance check. Measure whether the same release can now be traced and recovered by another engineer. Repeat the review after a material change to the deployment architecture, rather than treating the checklist as a permanent certificate.
- Engineering process and DevOps
- Production Runbook Template for a Small Engineering Team
- DORA Metrics for Small Teams: Definitions and Measurement
Frequently asked questions
Does the audit require a new CI platform?
No. First inspect the existing release path. Most initial improvements concern artifact traceability, permissions, verification and recovery rather than replacing the platform.
Should every deployment require manual approval?
Approval should match the risk and operating model. Automated evidence and limited permissions can be more useful than a routine approval with no clear decision criteria.
Is rolling back the container enough?
Only if the previous version remains compatible with the data and surrounding services. Review migrations and irreversible external effects separately.
Which release should we sample?
Choose a routine release, a release with database changes and a recent failure where available. Record what the sample does not cover.
What should an audit deliver?
A release map, evidence-linked findings, recovery gaps and prioritised changes with acceptance checks. A list of preferred tools is not an adequate result.
Bring the scope. We will help make it buildable.
Share the user journey, integrations and launch constraints. We can clarify the scope and prepare an estimate with assumptions and exclusions.
Further reading
A production runbook a small team can actually use
A runbook should help a responder move from a specific symptom to a safe decision.
DORA metrics for small teams: define what you measure
Use the current five DORA measures with a practical event log. Separate delivery evidence from individual productivity scores and misleading averages.
Code review process: reduce waiting without losing quality
Design code reviews around small changes, explicit risk, reviewer ownership and useful feedback. Measure waiting time without turning review into a quota.