...
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
...
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.