By Riccardo


2016-09-05 11:08:26 8 Comments

It is broadly accepted that developers should test updates through a staging site before releasing them to the live server, however once the development updates require modifications in Wordpress DB, things get complicated, as users in the live site will update the DB too.

The only (muddled) flow I can imagine is the following:

  1. Test on a local server (WAMP, XAMP, etc)
  2. Once ready to deploy, put the live site in maintenance mode
  3. Backup live site (Duplicator, sqldump, etc)
  4. Create a clone of locked live site to the staging site
  5. Upload modifications from local environment to the staging site
  6. Test the staging site
  7. Push the staging site to live.
  8. Remove maintenance mode

Drawbacks of the flow above:

  • downtimes may be longer than expected for users while the developer is carefully testing updates in the staging site;
  • may require manual management of modifications: for instance, siteorigin pagebuilder layouts are stored in the db, so once a layout is modified, it must be imported manually in the staging site; in this case it could be adequate to simply drop & import pages into the staging site, and if working, importing them in the live site

I wonder if is there a better and more automated way to achieve this.

What do you think?

EDIT, as requested, some solutions have been proposed in the past but none offers a definitive solution:

2 comments

@marekeiba 2016-09-10 12:44:30

Have a look at VersionPress which brings GIT versioning to the whole process (files and database)

As described on their site:

VersionPress provides painless staging. This means that you can easily create a safe testing environment for your changes and only merge them back when they are ready. Merge is the key word here – VersionPress handles situations where your live site had new content in the meantime seamlessly.

@Riccardo 2016-09-14 15:02:59

How can I verify reliability of this tool?

@montrealist 2016-09-05 12:11:15

Newer hosting providers that cater specifically to WordPress usually have tools in place to ease this pain. I put my clients on Pantheon which has this neat Git-enabled workflow, where code only moves up (from dev to staging to production) and DB stuff only moves down (vice versa from the code). Copying a database from production to staging is one click with their interface. Provided this workflow is respected, this pretty much eliminates the issue of ever messing up the production database, enabling me to always test my changes on a fresh clone of production DB data in either staging on development.

One doesn't have to use Pantheon - you can adopt a similar approach in your process using your own tools (Git + a DB cloning plugin like WP Migrate DB). I just find this way works well for me.

Question: why would you put your production site in maintenance mode while testing staging? There shouldn't be a need for that in a majority of cases. The only case I can think of is having some sort of very brittle system highly sensitive to additional user data being fed into it, with a catastrophic bug to boot - but that would likely be indicative of a different, larger, problem where one would need to rethink their product's entire architecture.

@Riccardo 2016-09-05 12:27:35

My provider allows creating one-click staging sites and push-to-live with a granular selection on tables being rewritten, nevertheless I still need locking users while the final test is run because part of the deployment is injecting developer-side data in the DB (sitebuilder page layouts for example are stored in the DB), requiring users to stop updating during this phase. If you have a better idea how to achieve this step I would be glad to share with you!

@Riccardo 2016-09-05 14:37:18

BTW, do you go through the dev/staging/live flow each time a little modification has been made? For example, slightly changing the layout of a page within the editor, or modifying a menu

@montrealist 2016-09-06 13:37:05

Yep - files go through dev -> staging -> prod every time (perhaps you can disable staging or dev - don't remember). Dev is for the dev team, staging is for QA or designer/client approval before pushing to prod.

Related Questions

Sponsored Content

3 Answered Questions

Ways of managing staging and production wordpress sites?

3 Answered Questions

[SOLVED] Maintaining synced staging/production WP sites

1 Answered Questions

1 Answered Questions

QA/Staging envirnoment for wordpress sites

Sponsored Content