Keeping Drupal deployments safe is all about confidence in the pipeline. Quality gates act as automated checkpoints that prevent code from progressing until it meets an agreed standard. In this guide we walk through the exact checks we implement for TrueCMS clients.
1. Define What "Good" Looks Like
Agree on metrics up front: linting, unit coverage, accessibility budgets, Lighthouse scores, and security scans. Document thresholds so engineers and stakeholders know when a change is ready.
2. Automate the Checks
Use GitHub Actions (or your preferred CI such as CircleCI or GitLab CI) to run ESLint, PHPStan, Jest, PHPUnit, and Playwright. Add pa11y or axe-core for accessibility. For visual regression at scale, wire in Diffy snapshots on key templates. Fail the build the moment a budget is missed.
3. Provide Fast Feedback
Surface results directly in pull requests with annotations and visual dashboards. Engineers should not need to open separate tooling to understand failures.
4. Enforce Promotion Rules
Only allow merges from branches with passing checks. For production releases, require smoke tests and Lighthouse assertions before tagging a release. Automate rollbacks when thresholds dip below safe limits.
5. Iterate and Improve
Review quality gate metrics monthly. When teams consistently pass, raise the bar. When a new issue sneaks through, add a new automated check and reset the baseline.
Quality gates do not slow delivery; they create confidence. When every change is measured automatically, teams ship faster with fewer late-night incidents.
6. A reference gate stack for Drupal
Our default stack focuses on speed of feedback and defence‑in‑depth:
- Lint & format: ESLint/Prettier for front‑end assets and PHPCS for PHP.
- Static analysis: PHPStan enforces type safety and catches defects early.
- Unit tests: PHPUnit for backend logic and JS tests where applicable.
- Behaviour tests: Behat scenarios for content workflows and editorial policies.
- Browser E2E: Playwright smoke and regression flows for critical journeys; Diffy for visual regression snapshots on key templates.
- Budgets: Lighthouse assertions and accessibility checks (axe/pa11y) on key templates.
Each gate is fast in isolation, but together they create a high signal wall. On pull requests we run the quick path first (lint, static analysis, unit), then fan out to Behat and Playwright suites. Production promotions repeat a smaller smoke set plus budgets to catch environment‑specific regressions.
7. Promotion rules that don’t block flow
- Require passing checks to merge to main.
- Auto‑label risky PRs (schema, auth, cache) to trigger extended suites.
- Enforce “green + reviewed” before tagging releases.
- If any budget dips (performance, a11y), fail fast and annotate the line of change.
8. Practical tips from the field
- Keep Playwright fixtures minimal and data‑independent for speed and reliability.
- Use Behat where language best communicates intent for editors and PMs.
- Cache Composer, node_modules, and Playwright browsers in CI to keep cycles short.
- Track flaky tests and fix root causes instead of adding retries.
Adopting this structure turns quality into habit. Once it’s routine, raising the bar becomes a safe, incremental change rather than a last‑minute scramble.