Our CI/CD Pipeline Template: Zero-Downtime Deploys From Day One.

Why we standardized on a single pipeline

Every project we take on gets the same CI/CD pipeline. Not because every project is the same, but because the deployment process shouldn’t be where you innovate. It should be boring, reliable, and identical everywhere.

After debugging unique deployment pipelines across 30+ projects, we built a template that handles 95% of use cases. The remaining 5% get project-specific additions bolted on top.

The pipeline stages

Our standard pipeline has 5 stages, each with a clear gate:

• Build — compile, bundle, create Docker image. If it doesn’t build, nothing else matters
• Lint & Format — ESLint, Prettier, PHP CS Fixer. Automated formatting means no style debates in PRs
• Test — unit tests, integration tests, and a smoke test against a disposable environment
• Security Scan — Trivy for container scanning, npm audit for dependencies, SAST for code
• Deploy — blue-green or rolling update depending on the infrastructure

Zero-downtime deployment

The key to zero-downtime deploys — central to our cloud infrastructure practice — is having two identical environments (blue and green) and switching traffic atomically:

• Deploy new version to the inactive environment
• Run health checks against the new environment
• Switch the load balancer to point to the new environment
• Keep the old environment running for 15 minutes as instant rollback
• If anything goes wrong, switch back in under 30 seconds

Database migrations

The hardest part of zero-downtime deploys is database migrations. Our rule: every migration must be backward-compatible. This means:

• Add columns before code that uses them ships
• Never rename columns — add a new one, migrate data, remove the old one in a separate deploy
• Never drop columns in the same deploy that stops using them
• Use feature flags to control which code path runs during the transition

This two-phase approach means you can always roll back the application code without worrying about the database being in an incompatible state.

Monitoring and alerting

Every deploy triggers a 15-minute monitoring window with elevated alerting. We watch error rates, response times, and resource utilization. If any metric degrades beyond thresholds, the pipeline automatically rolls back and notifies the team.