Deploying, rolling back, and auto-deploy

Outcome

By the end of this lesson, you will be able to ship a deploy and roll it back through an assistant, explain what auto-deploy changes about who is responsible, and choose between rollback and redeploy.

1. Concept

Three verbs cover most of what you will ever ask for on the ship side:

DEPLOY      create a service and ship its first version
REDEPLOY    ship the same service again, as a new deploy
ROLLBACK    go back to an earlier deploy of that service

All three are tier 2: reversible, bounded, possibly cost-affecting. That is the band a deploy belongs in, and it is why you can hand this to an assistant without handing over the estate.

Rollback and redeploy answer different questions

ROLLBACK    "the new version is bad, get me the old one"
            fast, and it does not rebuild anything

REDEPLOY    "the version is fine, the run is bad"
            rebuilds and ships again, same inputs

Reaching for redeploy when you meant rollback is the common mistake under pressure, because both produce a new deploy record and only one of them changes what is running.

Auto-deploy moves the trigger, not the responsibility

With auto-deploy on, a push becomes a deploy. The assistant can turn that on and off, and both directions are worth thinking about: on, and your branch is your release process; off, and every ship is deliberate.

2. Demo

YOU    "The new hello-api is throwing 500s. Roll it back."
ASSISTANT
  rolls back to the previous deploy       tier 2
  reports the deploy now running

YOU    "Turn auto-deploy off for that service until we fix it."
ASSISTANT
  sets auto-deploy off                    tier 2

YOU    "Ship it again now that the fix is merged."
ASSISTANT
  redeploys                               tier 2

3. Hands-on (6 min)

1. Ship a deploy of your capstone service through the assistant.
2. Ask it to roll back, and check which deploy is now live.
3. Ask for the deploy history and read the difference between the
   rollback entry and the original.
4. Turn auto-deploy off, then on, and notice that both are one
   sentence and both are tier 2.

Do it through MCP. The same task you just did in the console, asked in one sentence.

BEFORE  A service with at least two deploys in its history, so there is something to roll back to.
ASK     "Roll hello-api back to the previous deploy and tell me which one is live now."
CHECK   the deploy history. A rollback creates a new entry pointing at an old version, which is why the history is the honest record and the version number is not.

Tools behind it: list_deploys (read, Ship), rollback_service (write, tier 2, reversible), redeploy_service (write, tier 2, reversible), set_auto_deploy (write, tier 2, reversible), wait_for_deploy (read, Ship). The full catalogue is at zop.dev/learn/mcp-tools.

4. Knowledge check

Q1

The running version is broken and the fix is not merged yet. The right verb:

A. Redeploy
B. Set auto-deploy off
C. Update the service config
D. Rollback

Q2

What does a rollback add to the deploy history?

A. Nothing, it reverts the last entry
B. A note on the original entry
C. A new entry that points at the earlier version
D. It deletes the bad deploy

Q3

Auto-deploy is on. What has changed about responsibility?

A. Nothing, deploys still need approval
B. The assistant owns the deploy
C. Rollback is disabled
D. The branch is now the release process, so merging is shipping

5. Apply

Decide, per service, whether a merge should ship it. Write the decision down somewhere the team sees, because auto-deploy is invisible until the day it surprises somebody.

KEEP
  the rollback you performed, and the history entry it created

Related lessons

• L3: The three tiers, in depth
• L5: Diagnosing a bad deploy
• T1.M1.8.L2: The same deploy, asked in one sentence

Glossary terms touched

Deployment · Deployment config · MCP · Env var loading