Create staging site to test multisite update

  • map7890

    (@map7890)


    7 years, 10 months ago

    Hi,

    I am fairly new to WordPress so hope someone can help.

    We have a WordPress multisite installation and I would like to update it from 4.3.11 to 4.7.5/4.8.

    Before I update, I would like to create a staging site to test the update, plugins and install new themes before carrying it out on the live site. Essentially, I would like to know how to create a staging site, clone our live site – and anything that I do in the staging site should not affect the live site.

    I also have the Jetpack plugin installed, is there anything I need to think about or any issues that may arise because of this?

    Our WordPress multisite is hosted locally on a Linux CentOS Server.

Viewing 8 replies - 1 through 8 (of 8 total)
  • Neil

    (@neilgilmour)

    WCLDN 2018 Contributor

    7 years, 10 months ago

    Hey @map7890,

    I would suggest you use some sort of back up plugin to create a copy of your entire multisite network, then install this into your staging environment. You can then test out your updates without it affecting your live site.

    Check out Duplicator Pro which says it will migrate an entire network.

    Your sysadmin could set you up another bit of your local server as the staging site, or there is software which can create a ‘server’ on your computer – check out something like Local by Flywheel to easily create a staging environment if you’re on a Mac.

    Read this for letting JetPack know what’s going on when it wakes up confused in its temporary home!

    Hope that helps…

    jkhongusc

    (@jkhongusc)

    7 years, 10 months ago

    Are you a business? I can tell you how we do it at our enterprise. It is a multistep process and requires moderate expertise. It creates an exact replica of our production environment including using the same urls/hostnames.

    Thread Starter map7890

    (@map7890)

    7 years, 10 months ago

    Hey @neilgilmour

    Thanks for replying.

    I’ve just found out that our sysadmins will be cloning our site onto another identical server. Therefore, is there a way to set the cloned site to staging mode so it doesn’t affect the live site? Or should i be doing something else?

    Thread Starter map7890

    (@map7890)

    7 years, 10 months ago

    Hey @jkhongusc

    Thanks. We are not a business but any advice would be appreciated.

    jkhongusc

    (@jkhongusc)

    7 years, 10 months ago

    This is the basic process which we do to replicate our production data to dev/test/stage:
    1) export production database
    2) tar production WP files
    3) import production database to development database
    4) untar production WP files to development filesystem
    5) change your desktop /etc/hosts file to point to development system. example:

    10.1.2.3 main.domain.com # development IP address, production hostname

    This works great for us. We make our dev/test/staging environments an exact replica of production. The only hassle is remembering to modify your desktop/laptop /etc/hosts file to point to the right environment. Our WP system has 500 hostnames =)

    Our upgrade process is sync production to stage, upgrade WP core and plugins, and test. The entire process is documented. Then we set a date and deploy on production. Prior to production upgrade, we backup WP database and WP files.

    That is the enterprise process. Nothing on production should change without being tested first; and always have a backout procedure.

    • This reply was modified 7 years, 10 months ago by jkhongusc.
    Neil

    (@neilgilmour)

    WCLDN 2018 Contributor

    7 years, 10 months ago

    Doing stuff to the cloned site won’t affect the live site as there’s no link back to it. It’s effectively a whole other website, just identical (at the point of cloning). So it is already ‘staged’. Thinks out loud: if any links in your site are coded as full addresses like http://intranet.my-company.com/ then when you click them you’ll be taken to the live site.

    Remember those JetPack settings in the link above.

    When you’re happy it has all worked and updated you can either just make the cloned site the live one by changing your DNS (ask your sysadmins) or ask them to clone it back. Bear in mind that if lot’s of people are adding things to the live site while you’re testing in staging, then the databases will be out of sync. You’ll need something to merge the databases, but this isn’t my area of expertise – I would just search for a plugin which does it.

    In fact, assuming you’re in a work situation I would be getting the tech guys at work to do all this for me rather than relying on free support… 😉

    Neil

    (@neilgilmour)

    WCLDN 2018 Contributor

    7 years, 10 months ago

    In fact, assuming you’re in a work situation I would be getting the tech guys at work to do all this for me rather than relying on free support… 😉

    ^^ re-reading this it sounds a bit rude. I apologise – wasn’t intended that way. I just meant that if I had been asked to do this at work I wouldn’t want the responsibility if I wasn’t 100% sure it would work.

    This article explains more about how to merge the two versions you’ll end up with of the database: https://deliciousbrains.com/database-merging-made-easy/

    Keep us posted!

    Thread Starter map7890

    (@map7890)

    7 years, 10 months ago

    Thanks both!

    1) export production database
    2) tar production WP files
    3) import production database to development database
    4) untar production WP files to development filesystem

    As our sysadmins are going to create an exact replica of production onto a test server, all of this should hopefully get done as part of it.

    Our upgrade process is sync production to stage, upgrade WP core and plugins, and test. The entire process is documented. Then we set a date and deploy on production. Prior to production upgrade, we backup WP database and WP files.

    That is the enterprise process. Nothing on production should change without being tested first; and always have a backout procedure.

    My upgrade process is planned to be similar to this. I want to test all updates on the test site and will document it, once I’m happy that the upgrade went well then I will do it on the production.

    Doing stuff to the cloned site won’t affect the live site as there’s no link back to it. It’s effectively a whole other website, just identical (at the point of cloning). So it is already ‘staged’. Thinks out loud: if any links in your site are coded as full addresses like http://intranet.my-company.com/ then when you click them you’ll be taken to the live site.

    So does this mean that the cloned site will automatically be set to staged? Do I need to change any settings to say it’s staged or create a new domain/URL for this? I’m just a little bit concerned that anything I do in staged does not affect the production.

    When you’re happy it has all worked and updated you can either just make the cloned site the live one by changing your DNS (ask your sysadmins) or ask them to clone it back. Bear in mind that if lot’s of people are adding things to the live site while you’re testing in staging, then the databases will be out of sync. You’ll need something to merge the databases, but this isn’t my area of expertise – I would just search for a plugin which does it.

    I’m not planning to clone the staged back to production because lots of changes will have been made in the live site in that time so I’m not too worried about merging the databases. I only want to use the staging site to test the upgrade and if successful, implement it in production later.

    ^^ re-reading this it sounds a bit rude. I apologise – wasn’t intended that way. I just meant that if I had been asked to do this at work I wouldn’t want the responsibility if I wasn’t 100% sure it would work.

    Don’t worry, no offence taken 🙂

    • This reply was modified 7 years, 10 months ago by map7890.
Viewing 8 replies - 1 through 8 (of 8 total)
  • The topic ‘Create staging site to test multisite update’ is closed to new replies.