Setting Up CI/CD for Magento: Deploy Without Downtime

Most Magento deployments still follow the same ritual: SSH into the server, run git pull, execute magento setup:upgrade, cross fingers, and watch the site go into maintenance mode for 5-10 minutes. With proper CI/CD, you can deploy multiple times a day with zero downtime. Here's the exact pipeline we use for clients processing tens of thousands of orders daily.

Pipeline Architecture Overview

Our pipeline has four stages: Validate → Build → Test → Deploy. Every push triggers validation. Merges to the main branch trigger a full build and test cycle. Deploys to staging happen automatically; production deploys require a manual approval gate.

Stage 1: Validation

• PHP syntax checking with php -l on all changed files
• Static analysis with PHPStan (level 5 minimum) or Psalm
• PHPCS with Magento coding standards
• Composer dependency audit for security vulnerabilities
• GraphQL schema validation if using headless frontend

Stage 2: Build

The build stage compiles the Magento application and generates a deployable artifact. We use Docker to ensure the build environment is identical to production. Run composer install --no-dev, then magento setup:di:compile and magento setup:static-content:deploy. Package everything into a tarball or push to an artifact registry.

build:
  stage: build
  image: php:8.2-fpm
  script:
    - composer install --no-dev --optimize-autoloader
    - bin/magento setup:di:compile
    - bin/magento setup:static-content:deploy -f
    - tar -czf magento-build.tar.gz .
  artifacts:
    paths:
      - magento-build.tar.gz

Stage 3: Automated Testing

Tests run in parallel to minimize pipeline time. PHPUnit covers unit and integration tests. MFTF (Magento Functional Testing Framework) runs critical checkout and product flows. We cap the test suite at 15 minutes max — anything longer gets split into a separate nightly job. Minimum coverage threshold: 70% for custom modules.

Stage 4: Zero-Downtime Deployment

We use a blue-green deployment strategy. Two identical server pools (blue and green) sit behind a load balancer. The current live pool is blue. Deployment targets green: extract the build artifact, run setup:upgrade on green, warm the cache, run smoke tests against green's URL. Once smoke tests pass, the load balancer atomically switches traffic to green. Blue becomes the rollback target.

Rollback Strategy

Rollback should take under 60 seconds. Since blue is still running the previous version, a rollback is simply flipping the load balancer target back to blue. Maintain a deployment manifest that records which version is on which pool, so your team knows the current state at a glance.