...
Replicate production to the test instance to get a clone of production environment
Capture screenshots on the test instance before the upgrade is made
Perform upgrades on test
Verify screenshots to capture any regressions resulting from upgrades
Perform adjustments until screenshot tests pass
Perform the same set of upgrades on production
| Table of Contents |
|---|
Setup
The steps below are common to all upgrade tasks and should be done as a pre-requisite before an actual upgrade is attempted.
...
WordPress version upgrade
Note that automatic WordPress upgrades have been disabled through “DIGIMOD - Disable Automatic Updates” plugin and system upgrades must be done manually on a regular basis. This is done to prevent divergence between the WordPress version that is running inside the pod and the supporting image. In case of a node restart, the pod will reboot and a rollback to an older version will happen because the image has not been updated. This rollback can have adverse effects on the system as such downgrades are not expected. Therefore the system in place ensures that there is a parity between the image and the running version of WordPress.
Check for new WordPress version
...
Now that the latest image has been built to “latest” tag, rename it to “test” tag in order for the new image to be available to the test instance of the site. To do this, run the Rename latest WordPress tag workflow with default parameter (“test”).
Restart test instance
In order for the WordPress instance to pick the new image, the deployment must be rolled out. To do so, run the Restart Instance workflow with default parameter (“test”/”test”). Login to WordPress and verify that the new version of WordPress is now running.
Verify screenshots
Run the Verify Screenshots workflow to determine if any visual regressions took place as a result of an upgrade. Perform any necessary fixes and repeat the workflow until results are satisfactory.
Rename latest tag to production tag
Finally push the image to the production by running Rename latest WordPress tag workflow, this time with “prod” as an argument.
Restart production
Restart the production instance by running the Restart Instance workflow with “prod” as the first argument (the second argument is irrelevant). Verify that the new WordPress version is now running and apply any fixes that were done on the test instance to bring the site into alignment.
Updating Stock Plugins
There is currently no automatic way to perform upgrades of stock plugins. It is recommended to implement such approach using composer.json in combination with https://wpackagist.org/ service. This work has been started with the introduction of composer.json file, available on the plugins-composer branch.
To update stock plugins, perform the setup procedure as outlined below first. Next, manually upgrade all plugins on the test instance, verify the screenshots and then perform the same set of upgrades on production.
Updating Theme
The theme in use by digital.gov.bc.ca is a fork of the original BC Gov block theme and is available here: https://github.com/bcgov/bcgov-wordpress-block-theme-digimod. The fork does not contain any modifications beyond github workflows and it’s purpose is to control the release cycle of new versions of the theme.
Update Fork
First step in upgrading the theme is to bring the forked theme up to speed with the original repository. This can be done by creating a pull request.
Setup testing environment and publish new theme
Perform the setup process as described above first. Next, publish the new theme to test instance by running TODO. Once published, run the Verify Screenshots workflow and finally use the same workflow to publish the theme to production.
Deploying custom plugins
Custom plugins are located in the https://github.com/bcgov/wordpress-digimod repository. To deploy a single plugin, use the Deploy Plugin workflow and use Deploy Plugins workflow to deploy all plugins in the repository. It is recommended that new functionality is tested on test or dev instance of WordPress before deploying it to production. Screenshot testing may be employed to ensure there are no visual regressions on the site (these tests won’t cover backend plugin functionality).