In our previous discussion about Multi-Site staging, I mentioned encountering three primary issues following our migration to WPMUDev hosting. The second challenge also pertained to the staging environment, specifically involving the transfer of files from staging to production.
Updating Files from Staging
As part of our hosting protocol, we prioritize running updates that can’t be automated or those with potential issues through staging environments initially. This practice allows us to identify and resolve any issues, ensuring the site functions correctly before going live.
Similarly, when implementing code changes, we often lack a deployment setup for certain projects. Consequently, we need to transfer work from staging to production manually through file transfer.
Both processes can be executed manually by either reapplying updates on the live site and replicating any troubleshooting steps taken, or by copying updated files from our local environment and applying them to the live site, mirroring our actions in the staging phase.
The core issue here is time; repeating these processes on both staging and production can significantly increase the time spent updating a site. While WPMUDev’s “Move Staging to Production” feature appears to offer a simple solution, we discovered that this functionality deletes the file system and replaces it entirely. Given that we often work on active sites with clients making changes while we’re in the staging phase, this solution presents challenges.
Firstly, we cannot guarantee that clients haven’t uploaded new images or added plugins during our update process. Secondly, asking clients to refrain from making changes while we’re working on staging can be difficult to enforce.
In essence, we cannot afford to delete the file system each time we push staging to production due to potential compatibility issues. We aim to provide our hosted clients with a seamless experience, and interrupting them monthly for health checks and updates undermines the smooth behind-the-scenes monitoring and maintenance we strive for.
Consequently, we’ve reverted to manually running updates on both staging and production, which is time-consuming and taxing for developers. So, what’s the better alternative? Various ideas were proposed, including incorporating code into our hosting plugin. However, this approach would entail including sensitive details such as SSH users in the plugin, posing a significant security risk.
Instead, we opted to synchronize (rsync) changes from staging to live, ensuring the production environment is in maintenance mode during the process. This entire process can be executed via the command line, so we established standard production and staging SSH users, utilizing passwords to grant access to other developers as needed, rather than employing a public key.
Here’s how it works:
$ wp maintenance-mode activate --skip-plugins --skip-themes
$ rsync -avP --no-perms --no-times deployer-staging@piecode.tempurl.host:~/staging/public_html/wp-content/plugins/* ~/site/public_html/wp-content/plugins/
$ rsync -avP --no-perms --no-times deployer-staging@piecode.tempurl.host:~/staging/public_html/wp-content/themes/* ~/site/public_html/wp-content/themes/
$ wp maintenance-mode deactivate --skip-plugins --skip-themes
In this example, the files for plugins and themes from piecode.tempurl.host are synchronized into pie.co.de. After deactivating maintenance mode, we proceed to the updates page to ensure the database is updated accordingly.
This method, while involving some initial setup time, is quicker than individually running updates on both sites. We’re continuously exploring potential enhancements to this method, and we hope this article provides insights for others seeking alternatives.
I made adjustments for clarity and consistency with the previous tone. Let me know if you need further revisions!