The One Deploy Step We Always Automate First

Almost every team we take over DevOps for has the same thing hiding somewhere in their release process: one manual step that only one or two people know how to run safely, and that everyone quietly avoids touching on a Friday afternoon. It’s rarely written down properly. It’s usually a script someone ran from their own laptop, or a checklist in a private note.

We don’t start with the easy automation

The instinct is to automate the parts that are simple to automate first, since they’re quick wins. We do the opposite. We start by finding the riskiest manual step in the current process, the one that would cause the most damage if it went wrong or if the one person who knows it was on leave, and we automate that one first. It’s slower to build, but it’s the one actually keeping someone up at night.

What that step usually turns out to be

For most of the teams we’ve worked with, it’s one of three things: a database migration run by hand against production, a manual “flip the switch” step between a staging and live environment with no rollback path, or a deploy that depends on someone remembering the correct order of three or four separate commands. None of these are exotic problems. They’re just the kind of thing that gets left alone because it’s working today, right up until it doesn’t.

Automation isn’t the finish line

Turning a manual step into a script or a pipeline stage is necessary but not sufficient. The step also needs a tested rollback, a clear owner, and a way for someone other than the original author to run it under pressure without guessing. We’ve seen teams automate a deploy step and still get paged at 2am because the automation itself had no safe way to undo a bad run.

The payoff shows up in how releases feel, not just how fast they are

The real change our clients notice isn’t that releases get faster, though they usually do. It’s that a release on a Tuesday afternoon starts to feel the same as one on a Friday night emergency fix, because the process doesn’t depend on a specific person being awake and available. That’s the actual goal of DevOps work, in our view: making the release process boring enough that nobody needs to be a hero to run it.

If your team has a release step everyone quietly dreads, that’s usually the right place to start, not the last thing to get to. Get in touch if you want a second opinion on where yours is.