Deployment requires one person's laptop. What should change?
Nonrepeatable release processMove release knowledge and controlled artifacts into a reproducible authorized process. Protect secrets and access while ensuring another qualified person can execute and verify a release.
What to do now
- Document the current release steps
- Identify configuration and access dependencies
- Create a controlled repeatable deployment path
- Test it with another authorized operator
When to escalate
The current process creates unacceptable continuity or security exposure.
The technical owner and authorized release decision maker
Example
A release uses versioned scripts and managed credentials rather than undocumented local settings.
Mistake to avoid
Copying personal credentials into a shared script.
Prevent a repeat
Review real execution evidence and maintainability alongside feature completion; do not treat an unrun test as passed.
Suggested ApprovedFlow setup
- Tasks
- Documents
- Approvals
Track delivery tasks and attach engineering evidence; keep source control, build execution and technical controls in their actual engineering systems. See the platform
Related cases
- Our release process has no monitoring after deployment. What is missing?Unobserved production change
- A release introduces a serious defect. What should the team do first?Release incident response
- One expert is the only person who understands a critical component. What should we do?Single-person dependency
- Our expected benefit depends on another department changing its process. What should we do?Unowned benefit dependency