Phased WordPress updates across dozens of environments

Context

• Project type: CI/CD automation for WordPress core and plugin updates.
• Environment: GitHub Actions, WP-CLI, rsync, SSH-based Linux hosts, WordPress (single-site and multisite) across template, internal, staging, and production environments.
• Constraint: an agency-operated hosting platform running many independently configured WordPress installations for institutional clients needed to keep core and plugins current without applying untested changes directly to production, and without losing the ability to roll back a failed update.

Problem

Manually running wp core update / wp plugin update independently on every environment risks each site ending up on a slightly different, individually-untested set of versions, applying untested code straight to production, and having no fast, reliable rollback path if an update breaks a site.

Diagnosis

Most of what runs across the fleet — WordPress core, the shared theme, and the bulk of the plugin set — is identical between installations and only needs to be tested once, not once per site. A smaller set of client-specific ("divergent") plugins genuinely differs per environment and needs individual handling. This split suggested a "test once, promote everywhere" model: prove the update on dedicated template environments, then propagate the exact tested files outward rather than re-running the update command separately on every server.

Template · tested once●ok

Multisite

Single-site

promote exact tested files · byte-for-byte

Internal

1 · backup

Update

Staging

1 · backup

Update

Production

1 · backup

Update

branch off

Updated individually in each environment

✕failhalts only its own environment

Diagram of the phased update pipeline. Updates are tested once on two template environments, one multisite and one single-site. Status ok. The exact tested files are then promoted byte-for-byte to the internal environments, then staging, then production. In each environment a backup runs first, then the update. Divergent plugins branch off and are updated individually in each environment. Status fail: a failure halts only its own environment.

Actions

• Built a GitHub Actions workflow (manual dispatch, phase-selectable) that runs the actual update commands — wp core update, wp plugin update --all, wp core update-db [--network] — only on two dedicated template environments (one multisite, one single-site).
• Implemented per-environment divergence detection: each environment's installed plugins are compared against its rsync source, so only genuinely different ("divergent") plugins are updated individually via WP-CLI; everything else is promoted byte-for-byte.
• Promoted the tested baseline (core, theme, and shared plugins) via rsync --delete-after per directory, scoped so it only cleans stale files within a synced directory and never removes sibling divergent-plugin directories.
• Made a pre-update backup (excluding database and media, since the file backup is sufficient for rollback) mandatory before any environment is touched.
• Sequenced promotion in phases — templates, then internal environments, then staging, then production — with production pulling from its own linked staging environment so validated changes flow forward automatically.
• Isolated failures per environment (one environment failing does not block the others) and reported problems via GitHub Actions annotations rather than email, with a generated overview document as the single source of truth for current fleet state.

Result

• Verified operational result: a repeatable, automated, phased update pipeline spanning many independently hosted WordPress environments, with a mandatory pre-update backup and per-environment failure isolation on every run.

Relevant capabilities

GitHub Actions workflow design, WordPress multisite/single-site fleet management, WP-CLI automation, rsync-based deployment and promotion strategies, backup/rollback discipline, and designing automated pipelines that isolate and report failures without blocking unrelated work.

Capability 02WordPress & release reliabilityStability work for WordPress, WooCommerce and multisite, plus CI/CD, backups, rollback plans and deployment checklists for teams whose releases are fragile.