CI/CD Fundamentals — Continuous Integration and Delivery

What is CI/CD?#

CI/CD is a set of practices that automate the building, testing, and releasing of software. It's the backbone of modern DevOps and the primary way fast-moving engineering teams ship reliably.

Developer → Push code → CI pipeline → CD pipeline → Production
                          ↓                ↓
                     Tests pass       Deploy to env

Continuous Integration (CI)#

CI is the practice of merging code changes into a shared repository frequently (multiple times per day), with each merge automatically triggering a build and test run.

Goals:

• Catch integration bugs early (before they pile up)
• Maintain a consistently deployable codebase
• Give developers fast feedback (< 10 minutes)

Continuous Delivery (CD — Delivery)#

Continuous Delivery means every passing CI build produces a release artifact that can be deployed to production — but a human approves the actual deployment.

Continuous Deployment (CD — Deployment)#

Continuous Deployment takes it further — every passing build is automatically deployed to production without human approval.

CI → Continuous Delivery:   build → test → ✅ deploy to staging → 👤 human approves → deploy to prod
CI → Continuous Deployment: build → test → ✅ deploy to staging → 🤖 auto-deploy to prod

A Typical CI/CD Pipeline#

1. Code push / PR opened
2. Trigger CI pipeline
   ├── Checkout code
   ├── Install dependencies
   ├── Run linter / static analysis
   ├── Run unit tests
   ├── Run integration tests
   ├── Build artifact (Docker image, zip, binary)
   └── Publish artifact to registry / artifact store
3. CD pipeline (on merge to main)
   ├── Deploy to Dev environment
   ├── Run smoke tests
   ├── Deploy to Staging
   ├── Run E2E tests
   ├── 🔒 Approval gate
   └── Deploy to Production
4. Post-deploy
   ├── Notify (Slack, email)
   ├── Monitor (synthetic tests, alerts)
   └── On failure → automatic or manual rollback

Pipeline Stages in Detail#

1. Build Stage#

# GitHub Actions example
- name: Build Docker image
  run: |
    docker build -t myapp:${{ github.sha }} .
    docker tag myapp:${{ github.sha }} myregistry/myapp:latest

The build stage compiles code and creates an artifact — an immutable, versioned package (Docker image, JAR, npm package, zip). The same artifact flows through all environments.

2. Test Stage#

Layers of testing, cheapest to most expensive:

3. Artifact Storage#

After a successful build, push the artifact to a registry:

• Docker images → Docker Hub, Azure Container Registry (ACR), Amazon ECR
• npm packages → npm registry, Azure Artifacts
• Helm charts → OCI registry, GitHub Packages

Tag with the Git SHA for traceability:

docker tag myapp:latest myregistry.azurecr.io/myapp:abc1234

4. Approval Gates#

Gates control promotion through environments. Types:

• Automated gate — checks metrics (error rate < 0.1%, latency < 200ms)
• Manual gate — a team lead approves before production

5. Deployment Strategies#

Branching Strategies for CI/CD#

Trunk-Based Development (recommended for CI)#

All developers commit to main (trunk) frequently. Feature flags control incomplete work in production.

main (trunk) → always deployable
               ↑ every commit CI runs

GitFlow (for release cadence)#

main ──────────────────────────────► (releases tagged here)
      ↑                ↑
develop ──────────────────────────►
         ↑ feature branches      ↑ release branches

Key CI/CD Tools#

DORA Metrics#

The DORA (DevOps Research and Assessment) metrics measure pipeline health:

Common Interview Questions#

Q: What is the difference between Continuous Delivery and Continuous Deployment? Continuous Delivery means every build can be deployed to production but requires human approval. Continuous Deployment means every passing build is automatically deployed without human approval.

Q: Why should you build artifacts once and promote them? Rebuilding for each environment means the artifact that was tested in staging might differ from the one deployed to production (different dependency versions, timestamps, build environment). Build once with a known commit SHA; promote the same artifact.

Q: What are blue-green deployments? You maintain two identical production environments (blue = current, green = new). Traffic is switched from blue to green atomically. If issues arise, you switch back instantly. The old environment remains as a rollback target.

Q: What are DORA metrics? Four metrics used to measure DevOps performance: Deployment Frequency, Lead Time for Changes, Change Failure Rate, and Mean Time to Restore. Elite teams deploy multiple times per day with < 5% failure rate.

Common Mistakes#

• Running all tests in sequence — parallelize test stages to keep pipelines under 10 minutes
• Not tagging artifacts with Git SHA — makes it impossible to trace what's deployed
• Skipping staging — "ship from CI directly to prod" is fine for trivial apps, dangerous for anything real
• Manual approval for every environment — slow; automate gates for dev/test, add manual only for prod
• Large monolithic pipelines — split into smaller, independently runnable stages

What to Learn Next#

1. GitHub Actions — Practical Guide — build real pipelines
2. Azure DevOps Pipelines — enterprise CI/CD
3. Lab: Build a CI/CD Pipeline — hands-on from scratch