...
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
Verifying any other functionality that may be affected by the upgrade. Important: due to deficiency in automatic testing for certain features (such as custom plugins, i.e. QA Plugin), these features need to be tested manually to ensure the stability of the system
Perform adjustments until screenshot tests pass and any manual testing issues are resolved
Perform the same set of upgrades on production
It is recommended that the system updates are carried out on a regular basis (weekly or biweekly).
| 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.
...
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.
Rename latest tag to dev tag
“dev” tag is used for the development instance of WordPress. Once production has been upgraded, rename “latest” tag to “dev” to ensure that dev site is also running on latest WordPress version (restart dev using restart instance workflow).
Nginx version upgrade
Nginx version upgrade is similar to the WordPress upgrade.
Run Check for new nginx Docker image workflow with a desired nginx tag as input. This will update the appropriate docker file and trigger the build workflow. Refer to the upstream repository dockerfile for the current version of nginx ran by the GDX DES team.
Rename the latest tag in the image stream to “test” using Rename latest nginx tag workflow with default parameter (“test”)
Restart the test WordPress instance using Restart instance workflow and verify that it functions correctly.
Rename the latest tag in the image stream to “prod” using Rename latest nginx tag workflow with “prod” as the argument
Rest production server using the Restart instance workflow with “prod” as the argument
Rename “latest” tag to “dev” to ensure that dev instance of WordPress is also running the latest version (restart dev using restart instance workflow)
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.
...
Perform the setup process as described above first. Next, publish the new theme to test instance by running the Deploy theme workflow with default parameters (“test”/”test”). Once published, run the Verify Screenshots workflow and finally use the same workflow to publish the theme to production (this time with “prod”/”test” parameters - second one is irrelevant in this case).
Undo theme publish
When theme gets published, previous theme is kept. To undo the publish, simply activate the duplicated theme via the Themes interface in WordPress. Note: only one backup is kept, so if more than one publish was carried out in a row, the original theme will be lost.
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).
Manually adding a user to a WordPress instance
Sometimes it may be necessary to add a user to WordPress instance in order to login to the site (for example if a site was restored to an instance for which there is no KeyCloak config). To add a user in such cases, login to OpenShift, locate the the relevant deployment, navigate to the pod and open the terminal, in terminal, enter:
| Code Block |
|---|
curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar |
| Code Block |
|---|
php wp-cli.phar user create USERNAME username@example.com --role=administrator --user_pass=SECURE_PASSWORD |
Replace USERNAME and SECURE_PASSWORD with your username and password.
Important: Ensure that the password used is secure (of appropriate length and complexity) and delete the user once it is no longer needed. Avoid this approach unless necessary (Keycloak login is preferred).
Analyzing activity log
If it is necessary to determine the source of a change on the site, use the Simple History plugin available via Dashboard → Simple History to view the activity log of the site. The page can be used to assess for suspicious activity and track changes on the site as well as who is the author of those changes.
Summary of periodic checks and additional information
The following maintenance tasks should be carried out on periodic basis to ensure stability of the platform and keeping it up to date:
Check and install new WordPress versions
Check and install new nginx versions
Upgrade stock plugins (for example Advanced Custom Fields and All in One SEO)
Periodically update BCGov Block theme
Verify that backup is functioning correctly (verify log output of the Backup GitHub Worklfow and ensure https://digital-backup.apps.silver.devops.gov.bc.ca/ is running the latest version). To login to the WordPress site, add a user to the WordPress instance manually and check activity log (available through Dashboard) to verify there is recent activity.
Verify that file system volume and the database volume have sufficient space (digital-wordpress and digital-wordpress-mariadb PVCs, respectively)
Ensure that OpenShift namespaces (prod, test and dev) do not contain loose applications that are becoming out of date.