New Royal Academy of Dance Website – Building, Deploying & Testing the New RAD Site Code (Part 3)

We set up a CI/CD system for automatically building, deploying and testing the code for the new website, to simplify the process of deploying code changes between local, staging, and production environments; and to help ensure that implemented changes work reliably. This system was set up using GitHub Actions.

Custom website code is thus automatically deployed via a 3-step process, which runs whenever a developer Pull Request gets approved and merged:

1. Pre-Deployment Checks

These automated checks include linting of custom PHP code to detect syntax errors that could result in the website crashing; as well as running unit tests & integration tests. If the pre-deploy checks fail, the deployment process is halted, so that the subsequent steps do not take place.

The Unit tests are implemented using the WP_Mock library (which also incorporates the Mockery library), to allow various site components (such as implemented PHP functions and/or classes) to be tested in isolation; without it being necessary for a WordPress installation or an underlying database to be available. This makes it necessary for certain dependencies to be substituted for mock functions or classes, to simulate the existence of these dependencies.

The Integration tests are used to test whether the site components work correctly when they are integrated together, in an actual WordPress test environment with an associated database. The integration tests on this site use the WP PHPUnit test library, which is a mirrored version of the test library that is built into the development version of WordPress itself, but is available for automated installation via Composer, avoiding the need to manually copy the relevant files or install them via other more convoluted methods.

2. Code Deployment

The approved code changes get transferred automatically into the relevant staging or production environments in the hosting infrastructure, via Git. As part of this process, any implemented scripts that apply changes to data within the site database get run automatically.

In addition, the website CSS is compiled automatically from the source SASS code, as well as any JS or CSS assets associated with the custom blocks that have been implemented upon the site. These compiled assets are then transferred into the relevant hosting environment using Rsync.

After the code changes and compiled assets have been deployed successfully, the various caches within the hosting infrastructure are cleared automatically.

3. Post-Deployment Checks

Some additional automated checks are then run automatically against either the staging or live website as appropriate. These include End-to-End (E2E) Tests and Visual Regression Tests.

We use the Cypress testing framework for implementing and running E2E tests on this site. Cypress is a really nice and powerful tool that can run actions such as automatically visiting webpages and clicking on links, etc, within the context of a normal web browser. If a test fails as a result of new website issues, a developer can then debug the issue using standard developer tools built into the web browser. In this case, these tests are run in the background as part of the CI/CD process, and failed tests can be replayed and interactively debugged using the tools provided within Cypress Cloud.

We use the Percy service provided by BrowserStack to create automated snapshots of various pages on the site. If any visual changes get detected, these can then be reviewed, to confirm that no unwanted visual page changes have inadvertently arisen as a result of deploying the relevant updates. Of course in some cases the visual changes were intentional – for example when making code changes that were designed to adjust the appearance of the site, and/or in the case of website content updates. However these changes can be reviewed manually and approved.

If any of these checks fail (or if any visual changes need to be reviewed manually), automated notifications are sent via email and/or Microsoft Teams, to allow a developer to review them promptly and resolve any issues.

Applying WordPress Core & Plugin Updates

On the new website, the standard built-in WordPress updates mechanism is used to apply any released updates to the WordPress core installation, as well as updates to 3rd-party plugins and translation files. This approach allows the site to be set up using a more typical WordPress site structure, and it also tends to work more consistently for premium 3rd-party plugins than other approaches, without the need for a significant amount of additional infrastructure.

Nevertheless, a custom GitHub Actions workflow is also implemented, which uses the WP CLI to automatically install all available WP updates (including major WP releases as well as 3rd-party plugins, translations, core themes etc). This runs at frequent scheduled intervals, and applies these updates automatically into the staging environment. Upon completion, the server caches are cleared, and all of the automated checks described above are run (i.e. PHP code linting, unit tests, integration tests, E2E tests, and visual regression tests), to confirm that the applied updates have not caused any new issues.

The staging site can then be reviewed manually to confirm that the applied updates have not resulted in any issues that cannot be detected via the current automated checks; after which the GitHub Actions Workflow can be manually run to ensure that that updates have been applied and the automated checks have run in the production environment as well.

Now that we had a comprehensive & robust code deployment process in place, we were able to start working on the core functionality & design elements for the website itself.

Learn more in the fourth part to our technical series: Building the Core Functionality for the New Site »