DevOps when one person owns the release

What breaks when only one person can release?

The release works until that person is in a meeting, on leave, or the only one who remembers which script is current. The business then treats every change as a favor. Incidents take longer because the steps live in chat history instead of a path someone else can run.

What is the smallest reliable release path?

You do not need a platform team. You need a path a second person can follow.

1. One way in. Changes enter through the repository. Hotfixes on the server are an incident, not a habit.
2. One pipeline. Build, test, and publish happen the same way every time. Manual steps are written down and kept short.
3. One promotion. A tested build is what reaches production. Production is not where the first test happens.
4. One rollback. The previous build can be restored without reconstructing it from memory.
5. One log. Whoever releases records what went out, when, and how to undo it.

If those five exist, a second person can take a release without a guided tour.

What should you stop doing first?

Stop deploying from a laptop with a private environment file. Stop treating "it worked on my machine" as the release note. Stop adding a new script beside the old one without deleting or labeling the old one.

How do you know the path is real?

Ask someone who did not build the feature to run a non-production release using only the written steps. If they need a call to finish, the path is still a person, not a process.

Checklist

• Release steps written where a second person can find them
• Secrets kept out of the repository and out of chat
• A tested artifact is what production receives
• Rollback tried at least once
• The person who is not the usual releaser has run the path

---