CI/CD Pipeline Design: From Code Commit to Production Deployment

What Is CI/CD and Why It Matters#

CI/CD (Continuous Integration / Continuous Deployment) is the practice of automating the process of integrating code changes, validating them through automated tests, and deploying them to production — repeatedly and reliably.

Without CI/CD, software releases are manual, infrequent, and high-risk. With CI/CD, teams deploy dozens of times per day with high confidence because each change is automatically tested, built, and validated before it reaches users.

The goal is not just automation — it is the fast feedback loop. Engineers should know within minutes whether their code broke anything, not hours or days.

CI: Continuous Integration#

Continuous Integration is the practice of automatically running tests every time code is pushed. A well-designed CI pipeline runs:

• Linting and formatting checks
• TypeScript compilation (type checking)
• Unit tests with coverage threshold enforcement

• API endpoint tests with a real test database
• Service integration tests
• Security scanning (dependency vulnerabilities, SAST)

• Production build (confirms the app compiles without errors)
• Docker image build
• Image vulnerability scan

All three stages run on every pull request. PRs cannot be merged if any stage fails.

GitHub Actions: Pipeline Structure#

GitHub Actions defines pipelines as YAML workflow files in .github/workflows/. Key structural concepts:

• Triggers (on): Events that start the workflow — push, pull_request, schedule, workflow_dispatch
• Jobs: Independent units of work that can run in parallel or sequentially with needs:
• Steps: Sequential commands within a job
• Actions: Reusable units (actions/checkout, actions/setup-node)

Dependency Caching Dependency installation is the most time-consuming step in most pipelines. Cache `node_modules` using the hash of `package-lock.json` as the cache key:

This reduces CI time from 5-10 minutes to under 1 minute on warm cache hits.

CD: Continuous Deployment vs. Continuous Delivery#

Continuous Delivery means every commit is validated and could be deployed to production, but deployment requires a manual approval step.

Continuous Deployment means every commit that passes all automated tests is automatically deployed to production, with no human approval step.

For most teams, Continuous Delivery to staging with automatic promotion to production after time-limited observation is the right balance.

Environment Promotion Strategy#

A standard environment promotion flow:

1. Feature branches → Preview environments (ephemeral, spun up per PR, torn down on merge)
2. Main branch → Staging environment (automatic, immediate)
3. Staging → Production (automatic after 15-30 minutes with no alerting errors, or manual approval gate)

Ephemeral preview environments are one of the highest-value CI/CD investments — they allow QA, designers, and product managers to review changes in isolation without requiring local setup.

Deployment Strategies#

Rolling Deployments Gradually replace old instances with new instances. Traffic shifts progressively. Downtime-free but requires the new and old versions to be compatible simultaneously.

Blue-Green Deployments Maintain two identical environments (blue = current, green = new). Deploy to green, run smoke tests, then switch the load balancer to green. Instant rollback by switching back to blue. Higher infrastructure cost.

Canary Deployments Route a small percentage of production traffic (1-5%) to the new version. Monitor error rates and latency. Gradually increase traffic to the new version. Immediately roll back if metrics degrade.

Deployment Verification and Rollback#

Every deployment should include automated verification:

• Smoke tests: Run a minimal set of critical path tests against the deployed environment immediately after deployment
• Health check polling: Wait for the new deployment's health endpoint to return 200 before considering the deployment complete
• Error rate monitoring: Alert and trigger automatic rollback if error rates exceed baseline within the first 5 minutes

Rollback should be a single command or button click — never a stressful, manual process. Document the rollback procedure and test it regularly.