How do you design CI/CD for PHP apps with safe rollouts?

Long Answer

Shipping PHP applications (Laravel, Symfony, Slim, custom) safely and frequently requires discipline from code to production. My approach combines a test pyramid, contract testing, reproducible containerized builds, progressive delivery (blue/green or canary), and rollback + feature flags—all enforced by automated CI/CD gates.

‍

1) Test pyramid with fast feedback

Use Pest or PHPUnit as the unified runner and organize tests by purpose.

• Unit tests: Pure functions, services, value objects. No I/O. Run in milliseconds with parallelization (ParaTest). Enforce coverage gates on critical paths.
  
• Integration tests: Exercise framework kernels (Laravel HTTP kernel, Symfony KernelTestCase), real database and cache with Testcontainers for PHP (MySQL/PostgreSQL/Redis), and real migrations. Verify repository queries, mailers, queues.
  
• End-to-end (E2E): Target “golden journeys” (signup, checkout, webhooks) using HTTP-level tests or browser-driven Playwright/Cypress against an ephemeral environment spun up by Docker Compose or Kubernetes namespaces.
  

Add static analysis (PHPStan/Psalm), style (PHP-CS-Fixer), and optional mutation testing (Infection) on hot domains to harden assertions.

2) Contract tests to stop interface drift

For microservices and partner APIs:

• Consumer-driven contract tests (e.g., Pact for PHP or OpenAPI-based schema checks) generate expectations from consumers.
  
• Provider verification: the service under test must satisfy recorded contracts in CI.
  
• Schema diffs: treat OpenAPI/JSON Schema as versioned artifacts; allow additive (backwards compatible) changes during canaries, block breaking ones.
  

This reduces “it worked in my tests” incidents when clients or providers deploy unsafely.

3) Deterministic database fixtures

Avoid shared, flaky staging. Each CI job provisions its own database:

• Run framework migrations (Doctrine/Laravel) against Testcontainers.
  
• Seed idempotent fixtures via factories (Laravel model factories, Foundry/Fixtures for Symfony).
  
• For read-heavy flows, use snapshot datasets; for write paths, create factories per aggregate to avoid cross-test coupling.
  
• Ensure tests clean up via transactions or container teardown.
  

Deterministic fixtures produce repeatable builds and eliminate order-dependent failures.

4) Containerized builds and immutable artifacts

Use a multi-stage Dockerfile:

• Stage 1: Composer install with --no-dev and --prefer-dist, cache vendor.
  
• Stage 2: Build assets (Vite/Mix) if applicable; run framework optimizers (php artisan config:cache, route:cache; bin/console cache:warmup).
  
• Final image: minimal base (php-fpm + Opcache) and a separate Nginx sidecar or combined image. Expose health endpoints.
  
• Generate an SBOM (CycloneDX) and sign images. Push to a private registry.
  

Immutable images (tagged by Git SHA) enable surgical rollback and identical artifacts across environments.

5) Progressive delivery: blue/green or canary

• Blue/green: Run “blue” (current) and “green” (new) stacks. Warm “green,” run smoke tests, then switch the load balancer. Roll back by flipping traffic back to “blue.”
  
• Canary: Shift 5% → 25% → 100% traffic using gateway weight or service mesh (e.g., NGINX/Envoy/Istio). Gate steps with health signals: error ratio, p95 latency, queue depth.
  

Both require readiness/liveness probes, synthetic checks, and throttled rollout timers.

6) Rollback and feature-flag strategies

• Rollback: Re-deploy the last pinned image, not rebuild. Keep the last N images available.
  
• Schema safety: use expand–migrate–contract. Example: add nullable column and write both paths; backfill asynchronously; only later drop legacy column.
  
• Feature flags: LaunchDarkly/Unleash or Laravel Pennant/Symfony toggles. Ship dark, enable by cohort, tenant, or percentage. Keep kill switches for external-call paths, heavy queries, or cache layers.
  

Flags decouple deploy from release and are often the fastest incident mitigation short of traffic rollback.

7) Observability and promotion gates

Instrument with OpenTelemetry PHP (auto or manual) to emit:

• Traces: span attributes for endpoint, tenant, DB, cache, feature flags.
  
• Metrics: RED/USE (request rate, errors, duration; CPU/memory saturation), queue lag, job failures.
  
• Logs: structured with correlation IDs; redact PII.
  

Define SLOs (availability, latency). During canary, controllers watch burn-rate alerts; if thresholds breach, the pipeline auto-rolls back and disables related flags. Export traces to Grafana Tempo/Jaeger and metrics to Prometheus or Datadog for release dashboards.

8) CI/CD layout (typical GitHub Actions/GitLab CI)

1. Prepare: cache Composer; verify lock file; run composer audit or symfony security:check.
   
2. Static gates: PHPStan/Psalm, PHP-CS-Fixer, Rector (optional), secret scanning.
   
3. Unit: Pest/PHPUnit with ParaTest.
   
4. Integration: Spin Testcontainers (DB/Redis/Kafka), run migrations + fixtures.
   
5. Contract verify: provider verification against Pact/OpenAPI contracts.
   
6. Package: build Docker, warm caches, generate SBOM, sign image.
   
7. Ephemeral preview: deploy to short-lived env; run E2E + Lighthouse/API smoke + synthetic perf.
   
8. Blue/green or canary: progressive weights with OTel-driven gates; notify chat with links to traces/dashboards.
   
9. Post-deploy: run light synthetics and confirm SLOs; publish changelog and artifacts.
   

Result: a fast, repeatable pipeline that prevents interface drift, protects data, and enables reversible releases.

‍

Table

‍

Common Mistakes

• Relying on slow E2E while skipping integration tests with real DB/cache.
  
• Shared staging databases causing flaky tests and data races.
  
• Non-deterministic fixtures or seeding via production dumps.
  
• Building different artifacts per environment (no “build once, promote”).
  
• Shipping destructive DB migrations that block rollback.
  
• No contract verification—OpenAPI docs drift from reality.
  
• Single-shot cutovers without blue/green or canary guardrails.
  
• No feature flags or kill switches; mitigation requires hotfix rebuilds.
  
• Lack of observability, so rollbacks are based on guesswork.
  
  

Sample Answers

Junior:
“I run Pest unit tests and a few integration tests in CI. We build a Docker image and deploy to a staging environment. For production we use blue/green; if errors spike, we roll back to the previous image.”

Mid:
“My pipeline parallelizes Pest tests and spins Testcontainers for DB/Redis. Provider contracts (Pact/OpenAPI) verify in CI. We build a multi-stage Docker image with warmed caches. Releases use canary weights with health checks. Feature flags allow gradual enablement and instant disable. Rollback redeploys the last signed image.”

Senior:
“I enforce a pyramid (unit → integration → targeted E2E), consumer-driven contracts, and deterministic fixtures. Images are immutable, SBOM-generated, and signed. Delivery is canary with SLO-gated promotion using OpenTelemetry signals; schema changes follow expand–migrate–contract. Rollback is one command to a pinned image, plus kill-switch flags for risky paths. This yields fast, reliable, reversible PHP releases.”

‍

Evaluation Criteria

Strong answers include: a Pest/PHPUnit test pyramid with parallelization, contract testing (Pact/OpenAPI), deterministic DB fixtures (Testcontainers + migrations), containerized builds with immutable artifacts, blue/green or canary rollouts, and rollback + feature-flag strategy. Senior answers mention expand–migrate–contract for schema safety and OpenTelemetry or equivalent for promotion gates. Red flags: manual deploys, shared staging, no contract checks, environment-specific builds, or rollbacks that require rebuilding.

‍

Preparation Tips

• Convert tests to Pest and enable ParaTest.
  
• Add Testcontainers for MySQL/PostgreSQL/Redis; run real migrations and factories.
  
• Publish OpenAPI and add provider verification; try Pact Broker locally.
  
• Write a multi-stage Dockerfile (Composer, assets, PHP-FPM + Opcache) and push to a registry.
  
• Script blue/green or canary rollout (NGINX weights, service mesh) with health probes.
  
• Introduce feature flags (Pennant/Unleash) and a one-command rollback.
  
• Instrument with OpenTelemetry; build dashboards for error ratio and p95 latency.
  
• Rehearse an expand–migrate–contract change and a rollback drill.
  
  

Real-world Context

A subscription platform moved to Testcontainers + factories; flaky tests vanished and CI time dropped 35%. A marketplace added consumer-driven contracts; a breaking response change was caught pre-merge. A retailer adopted multi-stage Docker with warmed caches; cold-start latency shrank and rollbacks became instant. A fintech switched to canary with SLO gates (error ratio, p95 latency) and feature flags; a risky payment integration was disabled in seconds without rollback. Schema incidents disappeared after adopting expand–migrate–contract.

‍

Key Takeaways

• Use a Pest/PHPUnit test pyramid; prioritize integration realism.
  
• Verify APIs with contract tests and schema diffs.
  
• Create deterministic fixtures via Testcontainers, migrations, and factories.
  
• Ship immutable Docker images; “build once, promote everywhere.”
  
• Roll out with blue/green or canary guarded by health and SLOs.
  
• Rollback to a pinned image and use feature flags for instant risk control.
  
• Instrument with OpenTelemetry to make promotion and rollback evidence-based.
  
• Keep DB changes expand–migrate–contract to preserve reversibility.
  
  

Practice Exercise

Scenario:
You own a Laravel/Symfony API backing a checkout flow. Releases must be daily, downtime near zero, and rollbacks instant. Design CI/CD with tests, contracts, containers, progressive delivery, and rollback.

Tasks:

1. Convert tests to Pest; enable ParaTest. Add PHPStan/Psalm and composer audit.
   
2. Add Testcontainers for Postgres/MySQL and Redis; run migrations, seed factories, and ensure transactional cleanup.
   
3. Publish OpenAPI; add provider verification in CI against consumer contracts (Pact or schema checks).
   
4. Create a multi-stage Dockerfile (Composer install, cache warmup, PHP-FPM + Opcache). Generate SBOM and sign the image; tag by Git SHA.
   
5. Deploy to an ephemeral preview; run E2E smoke and synthetic perf.
   
6. Implement canary rollout (5% → 25% → 100%) with readiness probes; gate on p95 latency and error ratio.
   
7. Introduce feature flags for a new pricing engine; add a kill switch.
   
8. Script rollback to the last signed image and flag disable.
   
9. Perform an expand–migrate–contract DB change used by the pricing engine; prove rollback safety.
   
10. Instrument with OpenTelemetry and publish a dashboard (errors, latency, queue lag). Produce a release report linking test results, contracts, SBOM, and telemetry.
    
    

Deliverable:
CI/CD configs, Dockerfile, contract tests, rollout/rollback scripts, and dashboards demonstrating a safe, fast, and reversible PHP release process.