Lesson 13 · Senior CI/CD judgment

CI/CD truthfulness: what really happens after merge

How to describe the real delivery chain honestly, especially when the repo’s behavior is more nuanced than the usual “merge and it deploys” story.

Your win: explain what really happens after merge in this repo, why delivery truthfulness matters, and how to avoid giving a cleaner story than the system actually deserves.

In plain English Plain English: strong CI/CD understanding starts with telling the truth about when code is tested, built, deployed, and actually live.

Why this page matters more than it first looks

A lot of CI/CD explanations become smoother every time they are retold. A merge “deploys.” Staging is “automatic.” Production is “gated.” Those phrases are not always completely false, but they often hide the parts that matter most operationally: who triggers what, how long the gap is, where batching happens, and what counts as the true release boundary.

This is exactly why this page belongs in the senior section. Junior answers often stop at the presence of automation. Senior answers keep going until they can describe the real movement of the artifact through the system. If the story is batched, you say it is batched. If the story is manual at the end, you say it is manual at the end. If the story has waiting time, you name the waiting time.

The truthfulness rule A good CI/CD explanation names the real release boundary, the real delay, and the real human or automated step that moves the artifact forward.

What the honest story is in this repo

This repo is a good senior teaching case because the honest story is stronger than the simplified one. Merge to develop does not immediately deploy anything. It cuts a release tag. A 2-hourly cron later builds and auto-deploys that tag to staging. Production is still manual dispatch. If you compress that into “merge deploys,” you lose the operational truth that engineers actually need.

That loss matters in practice. If a fix merges at 10:05 and staging does not update until the next cron window, that changes debugging expectations, coordination with teammates, and incident response timing. “Is it deployed yet?” stops being a vague question and becomes a pipeline-state question.

Backend use case In this repo, the real path is push to develop → tbd.create_release_tag → tbd.auto-deploy-staging cron → tbd.build → tbd.deploy, with staging auto-deploying on the cron batch and production staying behind manual workflow_dispatch.

Common mistake Saying “merge to develop deploys staging” without naming the release-tag step and the 2-hour cron pickup that actually makes the deploy happen.

What stronger answers sound like

The strongest answers here sound concrete and calm. They do not oversell. They say: merge creates a release tag, the cron picks it up later for staging, and production is still manual. That answer is better not because it is longer, but because it is more operationally useful.

That is the habit this page is trying to build: do not clean up the pipeline story until it stops matching reality.

Revisit the repo map with timing in mind

Read the chain again, this time asking where the true release boundary is, where latency is introduced, and which parts of the story are automatic vs manual.

→ Repo CI/CD map
→ Trunk-Based Development

Check yourself (from memory)

Q1. What is the most truthful short summary of this repo’s post-merge deploy story?

The strong answer preserves the tag step, the cron delay, and the manual prod gate.

What makes a CI/CD explanation “truthful”?

recall, then click to reveal

It names the real release boundary, the real delay, and the real automated/manual step that moves the artifact forward, instead of compressing the chain into a cleaner but less accurate story.

Want a “walk me through what happens after merge” drill? Ask me.

Sources. Repo CI/CD map; Trunk-Based Development.