Set up continuous integration and deployment pipelines that build, test and release software automatically

What this dot point is asking

NESA wants you to define continuous integration and continuous deployment, describe what a typical pipeline does at each stage, and explain why teams adopt CI/CD.

The answer

Definitions

• Continuous integration (CI): every code change is automatically built and tested as soon as it is committed or proposed via a pull request.
• Continuous delivery: every change that passes CI is automatically prepared for release; humans choose when to deploy.
• Continuous deployment: every change that passes CI is automatically deployed to production. No human gate.

CI is universal; continuous delivery is common; continuous deployment is used by mature teams with deep test coverage.

The pipeline

A typical CI/CD pipeline runs every stage in order. Any failure halts the pipeline.

Each stage either passes (continue) or fails (stop, notify, do not deploy).

Tools

• GitHub Actions: YAML pipelines stored in .github/workflows/, free for public repos.
• GitLab CI: YAML pipelines in .gitlab-ci.yml.
• CircleCI, Travis, Jenkins: dedicated CI services.
• Argo CD, Flux: declarative continuous deployment for Kubernetes.

A worked GitHub Actions pipeline

A ci.yml for a Python project:

name: CI
on:
  push:
    branches: [main]
  pull_request:

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Set up Python
        uses: actions/setup-python@v5
        with:
          python-version: "3.11"

      - name: Install dependencies
        run: |
          pip install -r requirements.txt
          pip install pytest ruff mypy

      - name: Lint
        run: ruff check .

      - name: Type check
        run: mypy src/

      - name: Unit tests
        run: pytest tests/unit -v

      - name: Integration tests
        run: pytest tests/integration -v
        env:
          DATABASE_URL: postgresql://postgres:postgres@localhost:5432/test

The same pipeline runs locally (pytest, ruff, mypy) and in CI. Developers can reproduce CI failures on their own machine.

A worked deployment pipeline

A deploy.yml triggered on push to main:

name: Deploy
on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    needs: test  # depends on the CI job
    steps:
      - uses: actions/checkout@v4

      - name: Build container image
        run: docker build -t app:${{ github.sha }} .

      - name: Push to registry
        run: |
          echo ${{ secrets.REGISTRY_TOKEN }} | docker login -u user --password-stdin
          docker push app:${{ github.sha }}

      - name: Deploy to staging
        run: |
          kubectl set image deployment/app app=app:${{ github.sha }} -n staging
          kubectl rollout status deployment/app -n staging

      - name: Smoke test staging
        run: ./scripts/smoke-test.sh https://staging.example.com

      - name: Deploy to production
        run: |
          kubectl set image deployment/app app=app:${{ github.sha }} -n prod
          kubectl rollout status deployment/app -n prod

Quality gates

CI is the place to enforce standards across the team:

• Tests pass.
• Lint passes. Consistent style across the codebase.
• Type checker passes. Catches whole classes of bugs.
• Test coverage threshold. "No PR drops coverage below 80 percent".
• Security scans. SAST, dependency scanning.
• No secrets committed. Secret scanning.

Each rule is automated. Humans review the changes; the pipeline enforces the rules.

Rolling deployments and rollback

A production deployment should be safe. Patterns:

• Rolling deployment: replace instances one at a time. No downtime if the new version is healthy.
• Blue-green deployment: two parallel environments. Switch traffic from blue to green when green is ready.
• Canary deployment: send a small fraction of traffic to the new version. Promote if metrics look good.
• Feature flags: deploy the code with the feature disabled. Enable later for selected users.

Rollback should be one click or one command. Tag every release, retain the previous artefact, monitor key metrics for 5-15 minutes after deploy.

Monitoring

Deployments are not done when the new code is running. Watch:

• Error rates.
• Latency.
• Business metrics (signups, transactions).
• User reports.

Roll back if anything regresses.

Benefits

• Fast feedback: a developer learns within minutes whether their change passes.
• Confidence: every change is tested before it ships.
• More frequent releases: from quarterly to daily to many-per-day.
• Smaller changes: each release is smaller, so failures are less catastrophic.
• Consistency: the build runs in a clean environment, eliminating "works on my machine".
• Documentation: the pipeline is the build documentation.