Automated Standards Monitoring in a CI/CD Process
At The Code Company, we strive to maintain our industry-leading standards for code quality in all work that we produce.
The key to having a robust quality assurance (QA) program is 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 of 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 Webpack 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 straightforward. 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 before deploying to a staging environment as part of a larger linting job. If you are using the GitHub ecosystem, you benefit from the added advantage of easy visibility of failing builds.
Below is an example snippet of a GitHub Action to run a test build. An example linting job is shown further on.
jobs:
test-build:
name: Test Build
runs-on: ubuntu-latest
permissions:
contents: write
- name: Setup node
uses: actions/setup-node@v6
with:
node-version: "24"
- name: Global Composer setup
run: composer install --ignore-platform-reqs
- name: Run a test build
run: ./scripts/build-prod.sh
At The Code Company we normally keep our build scripts in separate bash files to allow reuse. 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 helps detect issues which are easily overlooked by a human reviewer.
The two primary tools we use are PHPCS and ESLint.
PHP Coding Standards (PHPCS)
PHPCS, as the name suggests, allows developers to check the compliance of PHP code with our coding standards. The WordPress team provides a convenient set of PHPCS rules, called WPCS which checks compliance with the WP coding standards. We’ve also created our own subset of PHPCS rules, which combines WordPress and WordPress VIP rulesets with some of our own coding standard preferences.
As with test builds, we typically run the PHPCS checks on any staging deployments, so any coding standards compliance issues are caught before a production release.
This is what a typical linting job will look like:
lint-phpcs:
name: Linting
runs-on: ubuntu-latest
permissions:
contents: write
steps:
- name: Check out our repo source code
uses: actions/checkout@v6
- name: Composer setup
run: composer install --ignore-platform-reqs
- name: Lint
run: ./scripts/phpcs.sh
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 from PHPCS in that we normally include it as a development dependency in our Node Package Manager (npm). We 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 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. Combined with IDE hinting and auto-formatting, these potential issues become non-existent.
