Code updates and Infrastructure upgrades have been mostly automated so that these operations can happen rapidly. This happens via multiple github repositories and actions.

Workflows

...

Create a new

...

WordPress instance

A new WordPress site can be created by executing the Create Wordpress Instance workflow. This will create all the necessary openshift resources in the specified environment, who’s names will be prefixed by the site-name input and the URL will be digital-site-nameapps.silver.devops.gov.bc.ca. The controlling infrastructure-as-code is implemented with kustomizedkustomize, and can be found in the wordpress-deploy-digimod repository. The action will also copy the wordpress WordPress cli to the container and perform a site install.

...

1. Create Wordpress Instance

2. Replicate Production

3. Sitemap Screenshots

4. Deploy theme

5. Deploy plugins

6. Verify Screenshots

Perform a test of a Wordpress upgrade

We check for wordpress and nginx upgrades with a manually triggered github actions workflow. This is a more complex process that involves several workflows over two repositories.

1. Every Monday at midnight, a workflow from the wordpress-deploy-digimod repository compares the version found in the dockerfile of the build configuration for wordpress, and compares it to the latest version found in dockerhub. If these are not the same, it updates the dockerfile in the repository.

2. A second workflow is then triggered when the dockerfile is updated, which builds the image and updates the image in openshift, under the ‘latest’ tag.

3. A third workflow in the wordpress-digimod repository operates on a cron job scheduled at 1AM on Monday, one hour after the first workflow is executed. It checks the status of the second workflow; if it is successful, it deploys the new version of wordpress to digital-latest. It first deploys from the dev tag, then takes screenshots, deploys from the latest tag, and then compares.

Configure the SSO for a site

...

Note: in case of OpenShift node failure that causes the failure of both the production PVC as well as the digital-backup PVC resulting in a situation where no snapshots are available on the OpenShift cluster to restore from, it is necessary to request a restoration from the offsite location back to the OpenShift cluster according to standard procedures. Note that this process have not been verified and may take some time (possibly days) during which the site will not be available. Once the restore is complete, the simplest way to restore would be to download the snapshot and perform a manual restore using the all in one plugin. Alternatively restore digital-backup site functionality and run the Restore Backup workflow as describe described above.

Note: restore backup process was not tested against production, however works properly with “test” as the target. It is therefore recommended to verify that restore backup process is working correctly.

...