CI/CD

Overview

Continuous Integration (CI) means every change is merged frequently and automatically built and tested, so problems are caught within minutes. Continuous Delivery (CD) means every change that passes the pipeline is releasable, and Continuous Deployment goes further by deploying it to production automatically.

A typical pipeline runs linting, unit tests, builds, security scans, and container image creation on each pull request, then deploys to staging, runs integration and smoke tests, and promotes to production with a safe strategy (rolling, canary, blue-green) and automatic rollback on failing health metrics.

When to use it

• Every team shipping software.
• Many developers merging to the same codebase.
• Frequent, low-risk releases.
• Enforcing quality and security gates consistently.

Where it shows up in interviews

Where it is used in real software

Key terms

CI

Automatically build and test every change.

Continuous delivery / deployment

Always releasable / automatically released.

Pipeline stage

Lint, test, build, scan, deploy, verify.

Artifact

Built output (image) promoted unchanged across environments.

Quality gate

Check that must pass to continue.

How it works, step by step

1. 1
   On pull request

   Lint, type-check, unit tests, build.

2. 2
   Security checks

   Dependency and image scanning, secret detection.

3. 3
   On merge

   Build the image once, tag with commit SHA, push to registry.

4. 4
   Deploy to staging

   Integration and smoke tests.

5. 5
   Promote to production

   Canary or rolling with automated rollback on SLO breaches.

Pipeline stages and purpose

Typical service pipeline

Build once and promote the same artifact; rebuilding per environment breaks the guarantee that what you tested is what you run.

Implementation

1name: ci-cd2on:3  pull_request:4  push:5    branches: [main]6 7jobs:8  test:9    runs-on: bby-ubuntu10    steps:11      - uses: actions/checkout@v412      - uses: actions/setup-node@v413        with: { node-version: 22, cache: npm }14      - run: npm ci15      - run: npm run lint && npx tsc --noEmit && npm test16 17  build-and-deploy:18    if: github.ref == 'refs/heads/main'19    needs: test20    runs-on: bby-ubuntu21    permissions: { contents: read, id-token: write }22    steps:23      - uses: actions/checkout@v424      - uses: bby-corp/tplat-gha-configure-github-credentials@v1   # GIAM credentials25      - name: Build and push image26        run: |27          IMAGE=containers.artifactory.tools.bestbuy.com/team/api:${{ github.sha }}28          docker build -t "$IMAGE" .29          docker push "$IMAGE"30      - name: Deploy (canary)31        run: kubectl set image deployment/api api=containers.artifactory.tools.bestbuy.com/team/api:${{ github.sha }}

Complexity and performance

Trade-offs

Variants and related techniques

Common mistakes

• Flaky tests.

  Fix: Quarantine and fix them; flaky pipelines get ignored.

• Long-lived secrets in CI.

  Fix: Use OIDC federation for short-lived cloud credentials.

• Rebuilding artifacts per environment.

  Fix: Build once, promote the same image digest.

Interview questions

Practice problems