MEP Runbook

What this screen is for

A runbook is the ordered set of steps that puts a release live. Rather than someone working from memory or a wiki page, the runbook is executed inside Fenwave: it has a status, it records each run, and anyone can see how far it got.

The MEP runbook is reached from a release, and also exists as its own page so it can be opened directly during an execution.

Before you start

To do this You need
View a release and its runbook deployment-manager.release.view.details
Act on a runbook deployment-manager.release.view.details.quick-actions

The release must exist first — see Releases.

Opening it

  • Standalone: /deployment-manager/mep/:releaseId
  • Embedded: the Execution History tab of a release

Both show the same body. The standalone page adds the page header, which makes it the better one to keep open on a second screen while executing.

The interface

📸 Screenshot Placeholder: The MEP Runbook page during an execution. Mark: (1) the runbook name, (2) the status, (3) the step list with progress, (4) the execution history.

# Control What it does When you’d use it
1 Runbook name Identifies this runbook Always
2 Status Its current state, including in progress The first thing to read
3 Steps The ordered steps and their progress During execution
4 Execution history Previous runs Answering “has this been tried before?”

While the status is in progress, the page polls and updates itself. You do not need to reload to watch it — and reloading during an execution is how people lose their place.

Walkthroughs

Execute a release

Requires deployment-manager.release.view.details.quick-actions.

  1. Open the release, go to Execution History, or open the standalone runbook page.
  2. Start the runbook.
  3. Watch the steps. The page updates on its own while it is in progress.
  4. When it finishes, confirm the outcome against Production.

Abort a run

Abort from the same controls. Aborting stops the runbook; it does not undo steps that already completed. Treat an abort as “stop here”, then decide deliberately what to do about what has already happened.

Check whether something was tried before

Open the runbook and read the execution history. A release that has been run, aborted and re-run tells a story the current status alone does not.

Scenario

A runbook stopped part-way through, at 2am, and you have just picked it up.

  1. Open the standalone runbook page for the release. Read the status first — in progress, aborted, or failed are three different situations.
  2. Read the steps. Find the last one that completed. That, not the error message, tells you what state the system is actually in.
  3. Read the execution history. If this release has been run before, the previous attempt may explain what the current one is tripping over.
  4. Check the release’s Deployments tab — what actually went out before the stop.
  5. Confirm against Production’s Events tab. Reality and the runbook should agree; where they do not, believe the environment and note the gap.
  6. Decide: resume, or abort and roll back. Do it through the runbook, so the record keeps being true for whoever picks this up next.

Step 2 is the one to internalise. At 2am the instinct is to read the error and act on it; the last completed step is what actually tells you where you are.

When it doesn’t work

Symptom Cause How to check Fix
Page shows nothing to run No runbook has been created for this release The release’s Execution History tab Create the runbook from the release
Status does not update The runbook is not in progress, so polling has stopped The status Expected — polling runs only while in progress
Cannot start or abort Missing release.view.details.quick-actions Access Explorer Ask for it; viewing alone is not enough
Aborted, but changes are still live Abort stops the runbook; it does not undo completed steps The step list and the Deployments tab Roll back deliberately; abort is not a rollback
Runbook says done, environment disagrees Someone acted outside the runbook Production Events Reconcile, and record what was done

Next