CI/CD Pipeline Architecture for Enterprises

The Problem This Blueprint Solves

Your deployment process involves an engineer SSHing into a production server and running git pull. Deployments happen on Fridays because "someone needs to watch it over the weekend." Rollbacks mean reverting a commit and redeploying, which takes 45 minutes and involves three people. Your team deploys once every two weeks because deployments are risky and painful — which makes each deployment riskier because it bundles more changes.

This blueprint documents the CI/CD platform I built for an enterprise SaaS company deploying 47 microservices an average of 23 times per day with zero-downtime rolling deployments, automated canary analysis, and one-click rollback in under 90 seconds.

What You Get

• Architecture diagrams — Pipeline topology from commit through build, test, security scan, staging deploy, canary analysis, and production promotion (Draw.io)
• Terraform modules — CodePipeline with CodeBuild stages, ECR repository with lifecycle policies, ECS rolling deployment configuration, CodeDeploy with canary traffic shifting, and artifact encryption with KMS
• Pipeline definitions — buildspec.yml templates for build, unit test, integration test, SAST scan (semgrep), container image scan (trivy), and deployment stages
• Rollback automation — CloudWatch alarm-triggered automatic rollback, manual one-click rollback procedure, and database migration rollback patterns

Key Architecture Decisions

• Canary deployments over blue-green for microservices — Blue-green doubles infrastructure cost during deployment. Canary shifts 5% of traffic to the new version, monitors error rates and latency for 10 minutes, then progressively shifts to 25%, 50%, and 100%. If any metric breaches the threshold, traffic shifts back to the previous version automatically.
• Trunk-based development over GitFlow — Long-lived feature branches create merge conflicts and delay integration feedback. Trunk-based development with feature flags means every commit is deployable, integration issues surface within hours not weeks, and you can release features independently from deployments.
• Security scanning in the pipeline, not after deployment — semgrep for SAST and trivy for container vulnerability scanning run as build stages. A critical vulnerability blocks the pipeline before the image is pushed to ECR. Shifting security left means vulnerabilities never reach production rather than being discovered by a monthly scan.
• ArgoCD for Kubernetes, CodeDeploy for ECS — If you run EKS, ArgoCD provides GitOps-based deployment with drift detection and self-healing. For ECS workloads, CodeDeploy's native canary and linear deployment strategies integrate with ALB target groups without additional tooling. The blueprint covers both paths.

Who This Blueprint Is For

• DevOps Engineers building their first automated deployment pipeline beyond manual deploys
• Platform teams creating a standardized deployment platform for multiple product teams
• Engineering Managers who want to increase deployment frequency while reducing deployment risk
• SREs who need automated rollback capabilities tied to production health metrics

Your First 48 Hours

Deploy the CodePipeline + CodeBuild + ECR Terraform modules into a sandbox account. Push the included sample application (a Go HTTP service) to trigger the pipeline. Watch it build, run tests, scan for vulnerabilities, push to ECR, and deploy to an ECS service. On day two, introduce a deliberate bug (an endpoint that returns 500 errors), push it, and watch the canary deployment detect the elevated error rate and automatically roll back. This demonstrates the full deployment safety net end-to-end.

Limitations and Trade-offs

Canary analysis requires sufficient traffic volume — at fewer than 100 requests per minute to the canary, statistical significance takes too long and you should use a time-based linear deployment instead. CodePipeline has a limit of 50 pipelines per region (expandable via support request). Database schema migrations require careful coordination with rolling deployments — the blueprint includes a pattern for backward-compatible migrations but does not cover all edge cases (column renames, table splits). ArgoCD adds cluster-level operational overhead — evaluate whether your team can maintain it before adopting GitOps.