# DevOps when one person owns the release

> How a small team makes releases repeatable when one person currently knows how production is updated.

## 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
---

Canonical page: https://appsoln.com/insights/devops-when-one-person-owns-the-release