Install Is One Verb; the Lifecycle Has Six

Most deployment tooling is built for its happy birth: the fresh install. You run the playbook, the thing exists, everyone’s pleased. Then real life starts — you need to update just the config, roll back a bad change at 2am, check what would change before you let it, upgrade to a new version, stand it up somewhere with no internet — and the tooling has nothing to say. Operators end up improvising the most dangerous operations by hand, exactly when they’re under the most pressure. Working on giving a deployment toolkit a proper operator layer drove the lesson home: install is one verb, but a system’s life has at least six, and each one deserves a first-class entrypoint.

Install is the verb you need least often

Here’s the irony: the fresh install — the operation tooling is usually built around — is the one you run least. You install something once. After that, for the rest of its life, you’re updating it, upgrading it, auditing it, occasionally rolling it back. The operations you perform constantly and the operation under the most pressure (the emergency rollback) are precisely the ones ad-hoc tooling neglects. We optimize for the demo — “look, it installs!” — and leave the daily reality and the worst-day reality as exercises for the operator.

You install once and operate forever. Tooling that only nails the install has automated the easy day and abandoned every hard one.

Name the verbs explicitly

When we laid out what the toolkit actually needed, the operator scenarios were a short, concrete list — and writing them down was itself clarifying:

• Fresh install — stand it up from nothing.
• Update — push a routine change (new config, new content) to a running system.
• Upgrade — move to a newer version, which is not the same as a fresh install and has its own pre-checks and rollback path.
• Rollback — get back to the last good state, fast and reliably, because this is the emergency verb.
• Audit / dry-run — report what would change without changing anything, so an operator can look before they leap.
• Offline / air-gapped install — do it where the network you assumed isn’t there.

Each of those is a distinct outcome with distinct safety considerations. Bundling them under “just run the install playbook and figure out the rest” is how you get an operator hand-editing files during an incident because the tool offers no rollback.

The dangerous verbs are the ones people improvise

The two that matter most are the two most often missing: rollback and dry-run. Rollback is the operation you reach for when something is already on fire — so it must be the most rehearsed, reliable, single-command thing you own, not a sequence of manual steps you’re inventing while production burns. Dry-run is the operation that prevents the fire — letting an operator see the diff before applying it. When tooling omits these, it’s not neutral; it’s actively steering people toward improvising the highest-stakes actions by hand. A toolkit that can install but not safely roll back has optimized for the good day and abandoned the bad one.

A real entrypoint per verb, not a flag and a prayer

“First-class” matters here. It’s not enough for the capability to be technically possible by passing the right combination of flags that an operator has to remember. Each verb should be its own named, documented, runnable entrypoint — “run this to roll back” — with its own guardrails, its own validation, and its own clear contract. The difference between “rollback is theoretically achievable if you know the magic invocation” and “there is a rollback command, here’s how you run it” is the difference between tooling an operator trusts at 2am and tooling they route around. Discoverability and a clear contract per operation are the product, not a nicety.

Ship the lifecycle, then write the runbook for each verb

So when I build or evaluate deployment tooling now, the question isn’t “does it install cleanly?” — it’s “does it have a first-class, documented path for every verb this system will need across its life, especially the scary ones?” Install, update, upgrade, rollback, audit, offline. Each gets an entrypoint and a runbook. It pairs with remembering that config management isn’t a scheduler, that environments should differ by config, not code, and that writing the runbook is itself the test of whether you actually understand the operation. Build for the whole life of the system, not just its first day. If you’ve retrofitted a real lifecycle onto install-only tooling, I’d like to hear how you scoped it.