Lesson 28 of 30

Release Trains vs. Continuous Deployment

Q: How would you decide between a fixed-schedule release train and deploying every merge to main automatically, for a given team?

A strong answer covers: Explains a release train (fixed schedule, batches whatever merged before the cutoff) vs. continuous deployment (every passing merge ships automatically); Identifies the real trade-off as predictability/coordination vs. speed/small isolated changes, not one being universally better; Names the actual deciding factor: how expensive a bad deploy is to detect and undo (test coverage, rollback speed) rather than team size alone; Notes that batching in a train makes a specific regression harder to isolate than a small continuous-deployment change would.

Ship on a fixed schedule and batch the risk, or ship every merge and spread it thin. Neither is the 'grown-up' choice — they trade cadence for safety differently, and the right one depends on your team.

14 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.

No quiz for this one — it's a practical topic

This topic is about judgment and practical tradeoffs more than a single right answer — a mock interview is the better way to test yourself on it.

Be interviewed on this →

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 Release Trains vs. Continuous Deployment

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

How would you decide between a fixed-schedule release train and deploying every merge to main automatically, for a given team?

A strong answer covers

Explains a release train (fixed schedule, batches whatever merged before the cutoff) vs. continuous deployment (every passing merge ships automatically)
Identifies the real trade-off as predictability/coordination vs. speed/small isolated changes, not one being universally better
Names the actual deciding factor: how expensive a bad deploy is to detect and undo (test coverage, rollback speed) rather than team size alone
Notes that batching in a train makes a specific regression harder to isolate than a small continuous-deployment change would

Likely follow-ups

Would you recommend continuous deployment to a team without strong automated test coverage? Why or why not?
A team says they do continuous deployment but a human approves every production push on Fridays. Is that accurate? What would you call it instead?
How would feature flags change your answer here?

Practice these with the AI interviewer →

The plain-language idea

There are two common answers to "when does a merged change reach production," and they sit at opposite ends of a trade-off between predictability and speed:

A release train leaves on a fixed schedule — every Tuesday at 10am, say — whether one change is ready or twenty are. Miss the cutoff and your change waits for the next train. Everyone knows exactly when a release happens, which makes coordination (release notes, QA sign-off, a support team bracing for a spike) easy to plan around.
Continuous deployment ships on every merge to main, automatically, with no schedule at all. There's no "next train" — a change either passes the pipeline or it doesn't, and if it does, it's live in minutes.

Neither is more mature than the other. A release train buys predictability and a stable review window at the cost of speed and batching risk. Continuous deployment buys speed and small, easy-to-isolate changes at the cost of needing serious automated test coverage and fast rollback machinery to be safe at all.

See it in a real thing: two triggers, two philosophies

A release train, cut on a cron schedule instead of a push:

name: Cut release train
on:
  schedule:
    - cron: "0 10 * * 2"   # every Tuesday, 10:00 UTC
jobs:
  cut-release:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: git checkout -b release/$(date +%Y-%m-%d) main
      - run: git push origin release/$(date +%Y-%m-%d)
      # Everything merged to main before 10am Tuesday is on this train.
      # Everything merged after waits for next week's.

Continuous deployment, triggered by the merge itself:

name: Deploy on merge
on:
  push:
    branches: [main]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: pnpm build
      - run: vercel deploy --prod --token=$VERCEL_TOKEN
      # Merged at 2:14pm, live at 2:17pm. No calendar involved.

Same underlying pipeline machinery — checkout, build, ship — pointed at two completely different triggers.

What people usually miss

Watch out

A release train doesn't remove risk — it batches it. If Monday's change and Thursday's change ship together on Tuesday's train, a regression that appears after the release could be caused by either one, and now you're bisecting a batch instead of pointing at a single commit. Continuous deployment's small, frequent releases make "what changed" a much shorter list to check.
"We deploy continuously" doesn't always mean continuous deployment. Plenty of teams run continuous delivery — every merge produces a deployable, tested artifact — and then promote that artifact to production on a human-decided cadence that looks a lot like a train. That's still continuous delivery, not continuous deployment, no matter how often the word "continuous" gets used.
Continuous deployment without strong tests and fast rollback isn't brave, it's reckless. Skipping the human gate only works if the automated pipeline actually catches what a human reviewer would have — and if it doesn't, you need to be able to undo a bad release in under a minute. Without both, you're not moving faster, you're just failing in production more often.

The genealogy: this is the choice the very first lesson set up

The mental-model lesson drew the line between Continuous Delivery — always release-ready, a human decides when — and Continuous Deployment — every passing change ships automatically. A release train is what Continuous Delivery looks like in practice once you add a calendar to the human's decision. This lesson is that same fork in the road, just with a concrete choice attached to it.