Staging Environment Workflow
Overview
All WordPress development must follow a spin up → develop → push → delete cycle for staging environments. Persistent staging environments are a liability: they consume server resources, drift out of sync with production, and create risk when pushed.
The goal is to always have exactly one active environment per site — production — and to treat staging as a temporary, disposable workspace.
The Standard Process
- Spin up a fresh staging environment copied directly from the current production site
- Develop — make all changes in staging, never directly in production
- Push the completed work from staging to production
- Delete the staging environment immediately after the push
Repeat this cycle for every discrete piece of work. Do not leave staging environments running between tasks.
Why This Matters
Prevents Stale Code Pushes
A staging environment that was created weeks ago is no longer a true copy of production. Pushing stale staging to production will overwrite recent changes and introduce regressions. Creating a fresh copy at the start of each task eliminates this risk entirely.
Automatic URL Rewriting
WP Engine automatically rewrites URLs when pushing from staging to production — staging.example.com becomes example.com, and http:// becomes https://. This only works correctly when using the native push workflow. Manual search-and-replace operations on the database are error-prone and should be avoided.
Server Resource Management
Every environment is a full copy of the site. Two persistent environments means double the storage; three means triple. Across ~40 managed sites, orphaned staging and dev environments add up to significant unnecessary load. Deleting staging after each use keeps the footprint minimal.
Reduces Coordination Complexity
Because the team is distributed across time zones, verbal coordination about who is using which environment is unreliable. The push-and-delete model means there is never ambiguity: if a staging environment exists, someone is actively using it right now.
Tracking Active Staging Environments
Because developers work asynchronously, a shared tracking mechanism is required so team members don't accidentally overwrite each other's work. The recommended approach is a simple shared sheet (Google Sheet or equivalent) with:
- Site name
- Who is working in staging
- Date started
- Status (in progress / ready to push / deleted)
This sheet must be kept current. An outdated entry is worse than no entry — it destroys confidence in the whole system. Developers should update the record when they spin up and again when they delete.
Owner: Isalia is responsible for developing and maintaining this tracking process.
Local Development
Developers may build on a local WordPress environment (e.g., Local by Flywheel) for speed. When local work is ready, the recommended path is:
- Push from local machine to a fresh staging environment (via Bitbucket or equivalent)
- Verify the work on staging against the live internet environment
- Push from staging to production
- Delete staging
Avoid uploading compressed file archives manually — this bypasses URL rewriting and version tracking.
What Not to Do
| Anti-pattern | Problem |
|---|---|
| Leaving staging environments running indefinitely | Wastes resources; environment drifts from production |
| Pushing from a staging environment that wasn't freshly copied | Overwrites recent production changes |
| Manually doing search-and-replace on URLs after a push | Error-prone; WP Engine handles this automatically in the push workflow |
| Working directly in production | No safety net; breaks are immediately live |
Related
- [1]
- [2]
- [3]
- [4]