Dev, Test, and Live environments: a safe deployment workflow

Most website outages that are not caused by infrastructure are caused by a change: a plugin update, a theme tweak, a module configured directly on the live site. The fix is not to stop making changes. It is to make every change somewhere safe first, in an environment that behaves like production, and to move it to production in a way that can be undone. That is all Dev, Test, and Live really are.

What each environment is for

Larger teams add a local environment on each developer's machine and sometimes short-lived feature environments for reviewing one change in isolation. The principle stays the same.

The golden rule: code moves up, content moves down

Code (themes, plugins, modules, custom code, and in Drupal, configuration) is written in Dev and promoted upward through Test to Live. Content (pages, media, users) is created by editors on Live and copied downward so Dev and Test reflect reality. Mixing these directions is how teams lose work: a database copied up from Test overwrites a week of editors' changes on Live.

How each platform handles configuration

Drupal separates configuration (content types, fields, views, settings) from content. Configuration is exported to files with drush config:export, committed to version control, and imported on each environment during deployment. That makes configuration changes reviewable and repeatable.

WordPress stores most settings in the database alongside content. The safe approach is to define as much as possible in code (custom post types, fields, and settings registered by a custom plugin) and to turn off file editing and updates on Live, so nobody can change code there directly. The constant DISALLOW_FILE_MODS in wp-config.php does exactly that.

Copying Live down safely

Test is only useful if it resembles Live, which means refreshing its content regularly. But a Live database contains real people's names, email addresses, and form submissions. Before it lands in a lower environment, scrub it:

• Replace user email addresses and reset passwords (drush sql:sanitize does this for Drupal).
• Remove or anonymize form submissions and any personal data.
• Disable outgoing email so Test never messages real people.
• Point payment, CRM, and other integrations at their sandbox versions.

Uploaded media can be large. Rather than copying every file, lower environments can fetch missing images from Live on demand.

A release checklist

1. The change is in version control and has been reviewed by a second person.
2. It has been deployed to Test and checked: the pages it touches, plus login, search, and forms.
3. An accessibility check has been run on any changed template.
4. A backup point exists immediately before the release.
5. The rollback is written down: redeploy the previous release, revert configuration, and restore the database only if a schema change requires it.
6. The release goes out in an agreed window, not during a peak.
7. After release: key pages load, error logs are quiet, and someone confirms the change works.

What makes Test trustworthy

Test should run the same PHP version, the same database engine, the same caching layers, and the same search service as Live. Every difference is a place where "it worked on Test" stops being true. The most common gaps are a missing CDN or object cache, a different PHP minor version, and a Test database many months out of date.

Signs your workflow needs work

• Changes are made directly on Live "because it is quicker".
• Test has not been refreshed from Live in months.
• Nobody can say exactly what was deployed last week.
• Rolling back means restoring the whole database.

Keep the number of environments no larger than your team can keep current. Three well-maintained environments are far more useful than five that have drifted apart.

How eWay runs environments

eWay provisions Dev, Test, Staging, and Production from infrastructure as code, so they match by design. Deployments go through Git-based pipelines with automated checks, peer review, and a documented rollback for every release. Updates are validated in a non-production environment before they reach Live. Database refreshes to lower environments are sanitized, and changes are held during agreed freeze periods such as registration or elections.

What to include in a support ticket

• The severity you would assign, P1 to P4 (see severity levels and response times)
• Which environment and site, and what you are trying to promote or refresh
• For a failed deployment: the time, what changed, and any error shown

eWay customers can open a ticket in the support portal or email support@ewaycorp.com at any time. See how to request support for all the options. Related reading: updating WordPress and Drupal safely and structuring Drupal environments. More on our WordPress and Drupal pages.