How Do Staging and Production Environments for WordPress Websites Work?

Some workflows depend on staging and production environments while others add an extra layer – a dev server that runs the latest bleeding edge of the application.

Structuring WordPress Environments

The second approach is structured in the following way:

  • Dev environment is constantly updated with the latest commits by the dev team.
  • The test/staging environment is pending review from the product management team or other stakeholders on the client’s end.
  • The production server is available to the public.

You can skip the dev server altogether although some hosting vendors provide 2 separate staging clones per site (or more if you want to test separate branches simultaneously).

Version-Controlled WordPress Projects

In terms of deployment, the best practices state that you ought to use a version controlled environment (git or svn) that’s pushed to the dev/staging site first. This could happen in various ways that I’ve described before.

So you push the changes to a repository that lives on the hosting and is automatically deployed, pull the changes directly on the server, or run a capistrano/Chef/Ansible deployment script that handles the heavy lifting.

The sync between staging and deployment may work in a similar matter – by pushing the same code base again to production once it’s ready to go. Depending on your hosting vendor and architecture, an easy “merge” button may exist (or a sync command that does that from the shell).

The one missing bit is the database sync. It’s a common problem with WordPress that gets trickier if you need to prepopulate database options, custom taxonomies, user data or anything else that is now configured in the staging environment.

Some hosting vendors again provide tools that let you override staging with production or even sync specific database tables instead. You can use WP-CLI and import a database export of posts or post types. Or use a plugin such as WP All Import/Export that allows for more complex export patterns.

In most cases, you won’t have to migrate a lot of custom database information to production. It’s either a couple of options that you can set/create manually, or there’s often a way to export a generated file that sets this up directly in the repository.