Automated Standards Monitoring in a CI/CD Process
At The Code Company, we strive to maintain our industry-leading requirements of code quality in all work that we produce. That’s why we attained our ISO 9001; world’s most recognised Quality Management System. This important certification demonstrates our ability to consistently meet the needs of digital publishers.
The key to having a robust quality assurance (QA) program is in not relying on a single process or check to ensure quality. There needs to be a range of proactive and reactive checks and balances to confirm that standards are being met at every point in the projects. From the time the first line of code is written to long after the code is in production.
It is also important to have both automated and human review throughout the process. Humans can be flawed — it is easy for a human reviewer to miss something in a large peer review. Automated checks can help pick up some of the commonly overlooked issues in code quality automatically, complementing the human element in QA.
Developing these standards to which we keep ourselves is only one part of the job; the real challenge is in developing and maintaining the QA processes that ensure these standards are met in all projects.
This is how we automated some of our QA process using a number tests in our continuous integration / continuous deployment (CI/CD) environments.
Testing NPM/Webpack/Composer Builds
Modern web development typically requires many preprocessing tasks when building a front end application and WordPress themes.
This includes build tools such as Babel for JS translation, Webpack/Gulp/Grunt for build automation, Sass for SCSS compilation and others.
As part of our continuous deployment (CD) process, we first run a “build”, which undertakes all of these tasks. This is all fairly standard and straight-forward. However, it is important to test that this build process will pass when it comes time to release an update to production. A missing dependency or misconfigured package can easily stop or break a deployment and cause a downtime event while it’s fixed.
Our standard configuration for this is to run a test build for all feature branches pushed upstream. If you are using Bitbucket in the Atlassian ecosystem, you benefit from the added advantage of showing failed tests in Pull Requests for that feature branch.
Here is what a pull request will look like when the test build fails:
Below is an example snippet of a bitbucket-pipelines.yml to run a test build. This will trigger the build script to run when any commit is pushed to a branch with the prefix feature/. This prefix is a standard that we use across the company to enable use cases such as this.
feature/*:
- step:
name: TEST BUILD
caches:
- npm-theme-cache
script:
- scripts/build-prod.sh
At The Code Company we normally keep our build scripts in separate bash files to allow reuse of them. So in this example we use the same build script during this test build as we do for the production build and deployment.
Coding Standards Check
An important aspect of quality assurance for any software project is ensuring compliance with coding standards. This keeps the codebase consistent by minimising the overheads in onboarding new developers, working on existing code and reducing coding errors/bugs.
We have adopted the WordPress Coding Standards for all PHP, JS and CSS/Sass code we produce as it is an industry standard.
Several automated tools are available for testing compliance with coding standards. This is definitely the preferred method and this is the type of issue which is easily overlooked by a human reviewer.
The two tools we use are PHPCS and ESLint.
PHP Coding Standards (PHPCS)
PHPCS, as the name suggests, allows developers to check compliance of PHP code to our coding standards. The WordPress team provides a convenient set of PHPCS rules, called WPCS which check compliance to the WP coding standards.
As with test builds, we typically run the PHPCS checks on feature/ branch commits, so any coding standards compliance issues are displayed on Pull Requests for review.
To ensure this is an efficient process, we only include files that have been changed as part of the branch when comparing to master. This way we are only checking compliance on updates that will actually make their way to production, ignoring any irrelevant changes.
This is what that script looks like:
for file in index.php `git diff master --name-only | grep 'php$' | tr '\n' ' '`; do
if [ -f $file ]; then
echo
echo "==== $file ================"
phpcs $file \
--standard=WordPress \
--report=json
echo
fi
done
Javascript Coding Standards (ESLint)
ESLint is the Javascript counterpart to PHPCS. We use it in the same manner to check compliance.
ESLint works a little differently to PHPCS in that we normally include it as a development dependency in our Node Package Manager (npm). We’ll then run it from within our theme.
This is the most compatible way of doing this as it integrates nicely with our developers’ IDE’s (Integrated Development Environment). We actually require our developers to use this feature as it gives them real time feedback on their code as they write it (linting).
This process is normally a little more straightforward as we run for the entire theme, like this: cd wp-content/themes/thecodeco npm run eslint
PHP Syntax Check, Avoid Those 500 Errors!
One final code quality check that we typically run is a PHP syntax check. It is all too easy to miss something a semicolon on the end of a line and have it white-screen a site.
Running a PHP syntax check to ensure all PHP code will compile and run is important.
This is very simple; we just run each file through php -l which is the linter that is built into PHP itself.
This simple check has only triggered on a few commits over the time we’ve been using it, but each time it has prevented errors on production sites.
