One click is not one step: shipping services and migrations together

“One-click deployment” is easy to promise and hard to deliver once a release spans several services and a schema change. The click is the easy part. What matters is everything that happens in the right order behind it, and whether a person can see and stop it.

Order is the release

A typical release has dependencies that are not visible in any one repository: a migration must complete before the services that read the new columns roll out; a backfill may need to finish before an old code path is removed. Write the order down as a plan, and make the plan the thing that gets reviewed.

Gates, not hopes

Put explicit gates between phases. A migration gate checks that the schema change applied and the data looks right. A rollout gate checks service health before the next service moves. Gates turn “I think it worked” into evidence.

Keep the context with the change

When something goes wrong, the first question is always “what changed?”. Keep the reviewed plan, the gate results and the health signals attached to the release, so the answer is one click away instead of spread across four tools.

Let people choose the level of automation

Some teams want an agent to prepare the sequence; others want to drive every step by hand. Both are valid. What should not change is the evidence trail and the ability to review before anything is applied.

Dorvi is built around exactly this: review the change with its context, ship services and migrations as one coordinated release, and keep the evidence, across the clouds you already run.