Quality and evolution

The quality of LydiaCMS is held by static analysis, tests and a release pipeline. Whatever can be automated, I automate: from checking the code to deployment.

Static analysis of PHP: PHPStan and Rector

PHPStan runs at the highest level (max) with 8 custom rules that guard the conventions of the project, and 14 custom Rector rules can fix deviations in bulk across all packages. The result is higher code quality: architectural mistakes are caught during analysis and not at runtime. Code: PHPStan, Rector.

Tests: Nette Tester and E2E in Playwright

  • The core has over 600 unit and integration tests in Nette Tester. They run in parallel and every thread works with its own database table prefix.
  • The sample application has a suite of E2E tests in Playwright (over 30 files) that covers the public part of the website and the administration.
  • The tests of the PHPStan and Rector packages run in the CI pipeline, while I run the core tests locally in Docker.

CI/CD pipeline in GitLab: automatic versions and publishing of packages

Packages are installed from a private Composer registry, so every release has to be uniform and without a manual step. All packages therefore use one shared GitLab pipeline, and a change of the process is made in a single place. It has three stages:

  • Check. composer validate --strict and a PHP syntax check across all sources. If it fails, the package is not released.
  • Tag. On the main branch the next version is computed and pushed.
  • Build. The pushed tag publishes the package to the Composer registry and an application picks up the new version with composer update.

Zero-downtime deployment

A new version of the website is not deployed straight into the running application. One script prepares a complete new release next to it and switches to it only once it has been verified:

  1. builds the release from the branch and installs dependencies without developer packages,
  2. attaches the shared data (.env, logs, uploaded files),
  3. starts the application as a trial, so a broken build never reaches the switch,
  4. backs up the database and runs the migrations (lydiacms:upgrade),
  5. verifies the website with a health check and, if it fails, rolls itself back to the previous release.

Backup and rollback

The database is backed up before the migrations. If there is a problem, the previous release (files) and the database from the backup can both be restored.

← LydiaCMS