Automation

From a manual runbook to an automated pipeline

The MU process works. The tooling around it is manual: pmus on a laptop with yes/no prompts, VRT diffs reviewed by eye, a Zendesk ticket per site per cycle, and status copied into Jira and Rocketlane by hand. MU Platform keeps the process and pmus, and automates everything around them.

Preview. Sites and customers below are sample data. Pantheon SSO and live MU data from portal.ps-pantheon.com come next.

Each stage, today vs MU Platform

StageTodayMU Platform
Detect updatesStarted by hand each cycle; security news via Slack bulletin feedsmanualScheduled portfolio-wide scan; advisories matched to installed versions automatically automated
Stage on Multidevpmus stage or Autopilot, run from a consultant laptopsemi-manualRunner job runs pmus stage server-side, in parallel, with the full log kept automated
Visual regressionpmus vrt:run (mu-vrt-local) + diffs reviewed by eyesemi-manualCloud VRT; threshold policy decides pass/fail, humans see only the regressions automated
Customer reviewZendesk ticket written per site per cyclemanualTicket generated from the run; UAT timer and approvals tracked, auto-proceed when due automated
Deploy to Devpmus deploy: interactive yes/no prompt per environmentsemi-manualSame pmus deploy; the yes/no prompt is answered by VRT policy, not a person automated
Deploy to Testpmus deploy: interactive yes/no promptsemi-manualAuto-promotes inside the site's deployment window automated
Deploy to Livepmus deploy: interactive yes/no promptsemi-manualWindow-aware Live deploy; one-click rollback to the snapshot automated
Notify & closeZendesk reply + Rocketlane and Jira PSOPP updated by handmanualZendesk, Rocketlane, Jira and Slack written from the run results automated

What it replaces

  • pmus run per site from a consultant laptop, answering yes/no prompts
    Runner jobs on Cloud Run run the same pmus, in parallel, prompts answered by VRT policy
  • mu-vrt-local (BackstopJS) diffs reviewed by eye
    Cloud VRT with stored diffs; people only look at regressions
  • One Zendesk review ticket written per site per cycle
    Review ticket generated from the run: updates, VRT link, UAT date
  • Site Inventory sheets, local JSON and Rocketlane fields
    One site registry in portal.ps-pantheon.com, synced with Salesforce subscriptions
  • Status copied into Jira PSOPP and Rocketlane (and drifting)
    Status and Last Deployment written back at every stage
  • Slack and email updates written by hand
    Release notes generated from what actually changed
  • "MU is a black box" to CSMs and customers
    Read-only status per site for CSMs, AMs and the customer

Time back to the team

Adjust the assumptions
Today
300h
per month
With platform
50h
review and exceptions only
Back to the team
250h
≈ 1.6 FTE / month

These are planning assumptions, not measured numbers. Replace them with real cycle times from the runner logs once it ships.

How it fits together

mu.ps-pantheon.com

This app. React Router + PDS on Cloud Run, same stack as load-test.ps-pantheon.com.

portal.ps-pantheon.com

System of record (Odoo): sites, orgs, Salesforce MU subscriptions, Rocketlane, Jira connectors.

MU runner

Cloud Run Job image with pmus, Terminus, Composer and BackstopJS (mu-vrt-local). One job per site cycle.

Notifications

Zendesk, Jira PSOPP, Rocketlane and #team-ps-managed-updates, written from run results.

Now

Visibility

  • Portfolio dashboard and pipeline board
  • Site registry replaces the spreadsheet
  • Security watch matched to installed versions
  • Connected to portal.ps-pantheon.com

Next

Run it server-side

  • Pantheon SSO (Auth0) for Pantheors
  • Runner job wraps pmus stage / vrt:run / deploy in Cloud Run
  • Import sites with pmus sheet:import data
  • Write-back to Zendesk, Jira PSOPP and Rocketlane

Later

Hands-off cycles

  • Scheduled cycles inside each deployment window
  • UAT timers and approvals tracked per site
  • Auto-rollback to the snpl snapshot on Live regression
  • Fast-track security cycles across the portfolio