If an approved release cannot proceed without one particular developer, the business still has a continuity problem. Approval alone is not enough. Someone else must have the access, instructions and authority to carry it out and respond if it goes wrong.
That is the practical value to seek from CI/CD: a repeatable deployment workflow with named owners and evidence at each decision point. The deployment button should execute an authorised process, not remove human judgment from it.
A deployment should not live in one person’s head
DORA describes deployment automation as deploying software to testing and production environments “with the push of a button”. Its guidance says manual deployment steps increase deployment time and the opportunity for error.
Use that principle to assess dependence on a developer or vendor. Ask for the deployment sequence to be taken out of personal memory and made repeatable through automation and a documented runbook. Keep people responsible for review, permission and recovery. The goal is to make execution transferable to another authorised maintainer, while retaining technical expertise and accountability.
CI, continuous delivery and continuous deployment
Continuous integration, or CI, means regularly combining code changes and using automated builds and tests to check the combined work. It answers whether that work can be built and passes the checks the team has defined. It does not, by itself, authorise a change to the live service.
Keep changes deployable, with manual production approval where required.
Deploy changes that pass the required checks without separate manual approval for each change.
Continuous delivery does not commit the business to continuous deployment.
The distinction is whether a production-ready change waits for a release decision or proceeds automatically after checks.Start with continuous delivery as the operating goal. DORA recommends it even for teams that never intend to adopt continuous deployment. Decide separately whether automatic production deployment suits your product and operating context. It is not a requirement for an effective delivery process.
What the button represents
The deployable artifact is the packaged output of a build, identified so the team knows which version it is handling. NIST’s DevSecOps reference model describes automated CI/CD components turning source code and configuration into artifacts, with mechanisms to verify quality and security before downstream integration.
Review source changes and identify what may proceed.
Build once, test and identify the resulting artifact.
Check that artifact in a pre-production environment.
Apply production permissions and record approval where required.
Promote the identified artifact through the authorised workflow.
Watch agreed signals and act on the prepared recovery plan.
Agree the recovery plan before deployment.
Ask the delivery owner to establish this path, adapting the checks and recovery plan to the system.Require the tested artifact to be promoted to production rather than rebuilt for it, with environment-specific configuration identified separately. The release record should make clear what was tested and what is being deployed.
Do not treat green tests or a completed deployment as proof of defect-free software. Agree what to observe afterward, who will watch it and what would trigger intervention. Checks are a condition for proceeding, not a substitute for post-deployment responsibility.
Separate technical readiness from production permission
Treat “the change passed its checks” and “the business authorises this release now” as separate decisions. In a continuous-delivery setup, agree who may approve production, who may execute the deployment and where approval is recorded. The same person may hold both responsibilities, but each should be explicit.
Ask the delivery owner to demonstrate the controls in the chosen platform: who can proceed, what prevents an unauthorised deployment and what record remains afterward. A CI/CD tool alone is not sufficient evidence of release control. As founder, ask for that demonstration rather than administrator access for yourself.
The minimum acceptable delivery checklist
Use this as a proposed operating baseline, not a universal standard or certification. Have the technical owner explain any exception and its consequences for continuity, control or recovery.
- Business ownership: keep the repository, cloud and CI accounts and credentials under business control. Name the owners of access administration and account recovery.
- Deployment identity: give the account used by deployment automation only the permissions it needs. Ask the technical owner to assess credentials that expire quickly, where the platform supports them.
- Secrets: require managed storage for deployment secrets outside repositories and developers’ laptops.
- Evidence: retain logs and an audit trail linking the reviewed change, artifact, checks, required production approval and deployment outcome.
- Fallback maintainer: have a second authorised maintainer demonstrate deployment using the runbook and their own approved access.
- Recovery: document data migrations, compatibility requirements, observation checks and the conditions for rollback or roll-forward.
Give data changes particular attention. Do not assume that restoring an earlier code version will undo a database migration or other data changes. Before approval, ask whether the previous application version remains compatible with the changed data, and whether old and new versions can operate together during deployment. Where reversal is unsafe, require a roll-forward plan: a corrective change that moves the system to a working state.
Questions to ask before the next release
Use the next release to test the baseline. Ask for answers tied to the actual system and release record, rather than descriptions of how the process is supposed to work.
- Open the last release record. Can the team trace the reviewed change to the tested artifact, any required approval and the deployed version?
- Walk through the last staging rehearsal with the fallback maintainer. Which steps required undocumented knowledge or access they did not have?
- Inspect the recovery plan for the next release. Does it address its actual data changes, compatibility constraints and intervention signals?
One question to take to the team
If the usual deployer were unavailable today, could a second authorised maintainer obtain production permission, deploy the already-tested artifact using the runbook and explain the recovery plan?
