Lesson 5 of 30

CI/CD Fundamentals

Q: What's the actual difference between Continuous Delivery and Continuous Deployment? People use them interchangeably, but they aren't the same thing.

A strong answer covers: Continuous Delivery: every change that passes the pipeline is ready to deploy, but a human still decides when it actually ships; Continuous Deployment: every passing change ships automatically, with no manual approval step; The distinction is about whether there's a human gate before production, not about how automated the build/test steps are.

Q: Your CI pipeline takes 45 minutes to run, and developers have started merging without waiting for it, or ignoring failures. What's actually gone wrong here, and how would you fix it?

A strong answer covers: CI's core value is fast feedback close to when the change was made — a slow pipeline breaks that, so people stop treating it as a real gate; Fixes: parallelize the test suite, cache dependencies between runs, and fail fast on the cheapest checks (lint/typecheck) before slower ones; Split out slow or flaky tests so a broken change is caught in seconds, not after a long wait.

CI catches problems early with fast automated feedback; CD ships validated changes — and 'delivery' vs 'deployment' is a real distinction people blur together.

12 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

Question 1 of 2

In a CI pipeline, why should lint and typecheck steps typically run before the slower test suite, rather than after?

Lint and typecheck steps produce more reliable results when run firstSo a broken change fails fast on cheap checks, instead of waiting behind a long test run to find outTests can't run at all unless lint and typecheck have already passed

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on CI/CD Fundamentals

What interviewers actually ask about this, and what a strong answer has to cover.

What's the actual difference between Continuous Delivery and Continuous Deployment? People use them interchangeably, but they aren't the same thing.

A strong answer covers

Continuous Delivery: every change that passes the pipeline is ready to deploy, but a human still decides when it actually ships
Continuous Deployment: every passing change ships automatically, with no manual approval step
The distinction is about whether there's a human gate before production, not about how automated the build/test steps are

Likely follow-ups

Why might a company deliberately choose delivery over full deployment, even if they trust their tests?
Where would a manual QA or staging-environment check fit into this — delivery, deployment, or neither?

Your CI pipeline takes 45 minutes to run, and developers have started merging without waiting for it, or ignoring failures. What's actually gone wrong here, and how would you fix it?

A strong answer covers

CI's core value is fast feedback close to when the change was made — a slow pipeline breaks that, so people stop treating it as a real gate

The plain-language idea

Continuous Integration (CI): every code change automatically gets built and tested before it merges — catching a broken change in minutes, not at release time weeks later.

Continuous Delivery and Continuous Deployment get used interchangeably, but they're different:

Delivery — every change that passes the pipeline is ready to ship, but a human still decides when it actually goes out.
Deployment — every passing change ships automatically. No manual approval step.

See it in a real thing: a typical pipeline

on: pull_request
jobs:
  ci:
    steps:
      - run: pnpm install
      - run: pnpm lint          # cheapest checks first
      - run: pnpm typecheck
      - run: pnpm test
      - run: pnpm build
  # then, separately, on merge to main:
  deploy-staging:
    steps:
      - run: deploy to staging automatically   # Continuous Deployment, to staging
  deploy-production:
    steps:
      - run: wait for manual approval          # Continuous Delivery, to production
      - run: deploy to production

Notice the order inside the CI job: lint and typecheck run before the slower test suite. A broken change fails in seconds on the cheap checks, instead of waiting behind a 20-minute test run to find out.

CI/CD: automated gates between commit and productionStep 1 of 3

git push triggers a pipeline automatically: install deps, run tests, build.

What people usually miss

Watch out

"The build passed" and "the tests passed" are different gates. A green build with no meaningful tests just means the code compiled without crashing — it says nothing about whether the code actually works.
Delivery vs. deployment is about a human approval step, not about automation. Both can be fully automated up to that point — the difference is purely whether a person clicks "go" before production, or the pipeline does.
Flaky (randomly failing) tests can be worse than no test at all. A test that sometimes fails for no real reason trains the team to re-run it and ignore red — which erodes trust in every other, genuinely meaningful failure in the same pipeline.
Order matters inside a pipeline. Cheap, fast checks (lint, typecheck) should run before slow ones (integration tests, builds) — fail fast on what's cheap to check, so a broken change is caught in seconds, not after a long wait.

Why this matters in interviews — and why big companies depend on it

At any company with more than a handful of engineers, CI/CD is what lets many people ship to the same codebase daily without stepping on each other or shipping something broken straight to real users. It's infrastructure, not a nice-to-have — and "what would you do if the pipeline is too slow to trust" is exactly the kind of practical, scenario-based question that comes up once you're past pure language/framework trivia.