A Magento agency without CI/CD pays the same tax on every project: manual deploys, “it worked in dev”, and Friday-afternoon releases nobody trusts. A pipeline converts releases from an event into a routine. Here is the shape we run across client work, adaptable to GitHub Actions, GitLab CI or Bitbucket Pipelines.
The Stages That Earn Their Place
1. Static checks (seconds, run first)
composer validate- PHP_CodeSniffer with the Magento standard - catches the obvious before humans do
- PHPStan at a level your codebase passes today, ratcheting up over time
2. Build (minutes)
composer install --no-dev --prefer-distfrom the lockfilebin/magento setup:di:compile- proves DI wiring is valid- Static content deploy for production mode
- The output is a build artifact (tarball or image): the same bytes that will deploy, tested as a unit
3. Test (minutes, parallel)
- Unit tests if the project has them
- Smoke checks against a deployed review environment: homepage 200, checkout reachable, cron runs
4. Deploy (gated)
- Staging automatically on merge to
develop; production on tagged release or explicit approval - Deploy the artifact, run
setup:upgrade, warm caches, smoke test, and only then flip traffic
The Artifact Principle
Build once, deploy the same artifact to staging and production. Projects that run composer install on the production server have two failure modes CI exists to prevent: deploys that differ from what was tested, and a Composer outage becoming your outage. Build in CI, ship the tarball.
Per-PR Environments
For agency work with parallel client changes, ephemeral review environments (a containerised stack per PR, seeded with sanitised data) change the quality conversation: clients review a URL, not a screenshot. They cost infrastructure and data-sanitisation effort - worth it on active projects, overhead on maintenance accounts.
The Checks Worth Automating (and the Ones Not Worth It)
Automate: coding standards, DI compile, static deploy, smoke tests, link checks on staging. These are mechanical and catch real breakage.
Do not over-automate: full-browser E2E suites on every commit are slow and flaky for most Magento projects. A small, reliable E2E set on staging releases beats a huge flaky one on every push. Flaky tests teach teams to ignore CI - the one outcome worse than no tests.
Multi-Client Reality
Agencies run this pipeline per client project from a shared template. Parameterise the differences (server targets, PHP versions) and keep the stage logic identical, so a developer moving between projects finds the same release shape everywhere. Template the pipeline once in your platform repo and subtree or copy it into projects with a documented sync process.
CI/CD’s real product is confidence: anyone on the team can release on a Tuesday morning because the pipeline, not a hero, carries the risk. Build the pipeline before the project needs it - retrofitting it mid-fire is how it never happens.