Fabric CI/CD: Merge the whole ladder, or cherry-pick what is ready?

Key takeaways

Multi-dev Fabric ladders (test → ppe → main) rarely have a tip that is entirely ready.
Merging the whole tip promotes unfinished work with the ready work.
Safer shape: cherry-pick selected squash-merge commits onto a short-lived promotion branch, then PR into the next env.
Cherry-pick without the temp branch + PR is incomplete promotion hygiene.
Pair git selection with Variable Library / item rebind; git alone is not a deploy story.
At scale, cherry-pick hell is real; shrink the release set and document the written pick list.

You have three developers on test. Feature A is proven. Feature B is half-built. Feature C still points at a spike . Someone opens a PR from test tip into ppe because "that is how the ladder works." PPE now owns unfinished work you never meant to stage.

Promote by commit, not by tip. Select the squash-merge commits that are ready, park them on a short-lived promotion branch, open a PR into the next environment branch, then deploy. Keep the blast radius honest.

Named model: promote by commit, not by tip

Tip: the current head of an environment branch (test, ppe, main). Often mixes ready and unfinished work in a multi-dev estate.
Selected commits: squash-merge SHAs you can name as the release set for this promote.
Promotion branch: short-lived branch cut from the next-env tip; cherry-picks land here, not on the protected ladder branch.
PR gate: temp → next env. Review, checks, and rebind story ride with the PR; cherry-pick alone is not the gate.
Contract: blast radius equals the commits you named, not everything that happened to sit on the tip.

Named model: tip promote versus selected commit promote

Figure 1. Named model: promote by commit, not by tip. Tip merge inherits WIP. Selected squash commits keep unfinished work on the lower rung.

Context and constraint

This note is about git promotion shape across a Fabric environment ladder. It sits next to , which asks a different question: what the deployer will reconcile in the workspace once you trigger a promote. Here the question is which commits you allow onto the next branch before that deploy runs.

Constraint set: multi-developer; unfinished features sitting on test; need selective promotion into ppe or main without waiting for every in-flight change. Classic merge-the-ladder diagrams look clean in a slide. They break when the tip is a shared parking lot.

Community threads on Microsoft Fabric CI/CD keep landing on the same clarification: cherry-pick is not a lone git cherry-pick onto the protected next branch. It is cherry-pick onto a temp branch, then PR that branch into the next env. That is the model this note teaches.

Design

1. Draw the tip honestly

List what is on test tip before you open a ladder PR. Ready feature A. WIP feature B. Spike leftovers for C. If you cannot name the unfinished set, you are not ready to merge the tip. Figure 2 is the fork: tip merge versus selected squash commits.

Tip merge of A plus WIP versus selecting only ready squash commits

Figure 2. Path A merges the whole tip and promotes WIP. Path B selects ready squash commits; unfinished work stays on test until its own release set.

2. Prefer squash-merge SHAs as the release unit

Feature PRs that land as squash merges give you one SHA per feature. That SHA is the promotion atom. Without squash (or an equivalent clean commit contract), selective promotion becomes archaeology across noisy merge commits. Write the release set as a list of SHAs and owners before anyone touches git.

3. Use a short-lived promotion branch, then a PR

Cut promote/test-to-ppe-<date> (or similar) from the ppe tip, not from test tip. Cherry-pick the named SHAs onto that temp branch. Resolve conflicts there. Open a PR into ppe. Do not push cherry-picks straight onto protected env branches. Figure 3 is that four-step shape.

Select commits, temp branch, PR, then deploy

Figure 3. Cherry-pick isolates the change set. The PR is the promotion gate. Deploy runs after merge, with Variable Library and rebind in the same story.

4. Deploy is still workspace surgery

After the PR merges, fabric-cicd or deployment pipelines still decide the workspace reconcile set. Selected git history does not shrink a blind workspace publish by itself. Keep item filters, dry-runs, and the never-blind list from the blast-radius note. Pair this promote with Variable Library deploy targets so lakehouse and workspace ids remap per stage instead of riding Dev bindings upward.

5. Know when tip merge is still correct

If the tip is a release train that is entirely ready (every open feature either shipped or parked off the branch), tip merge is honest and cheaper. Selective cherry-pick is for the common multi-dev case where test is intentionally mixed. Do not invent cherry-pick theater when the tip is clean.

6. Bound cherry-pick hell

At scale, hundreds of commits between rungs make one-by-one picks painful. Shrink release trains, keep features small, prefer fewer SHAs per promote, and retire abandoned WIP from the lower branch so it does not haunt every pick list. Document the written pick list in the PR body so the next operator is not guessing.

Failure modes

Merging the tip because the ladder diagram said so. Unfinished notebooks and bindings land in ppe with a green merge.

Cherry-pick onto the protected env branch with no PR. No review surface, no checks, no written release set, hard to audit.

Forgetting the PR after a local cherry-pick. Temp branch sits on a laptop. Next env never receives the change. Operator thinks they promoted.

Treating cherry-pick as pure git without rebind. Items move; lakehouse and connection ids still point at the lower stage. Deploy "succeeded." Data plane lies.

Cherry-pick hell with no release-train hygiene. Hundreds of commits, unclear owners, conflict storms. The process collapses back into tip merges under pressure.

Skipping Variable Library / deployment rules. Selective git promote still needs stage-safe bindings. Git selection is not a substitute for the environment map.

What to copy / what not to copy

Copy

Promote by commit, not by tip, when unfinished work shares the lower rung.
Written release set of squash-merge SHAs before cherry-pick starts.
Short-lived promotion branch cut from the next-env tip, then PR into that env.
Deploy after merge with fabric-cicd / pipeline dry-run and Variable Library remap.
Honest tip merge only when the tip is entirely ready.
PR body that lists SHAs, owners, and rebind notes.

Do not copy blindly

Cherry-pick is operational cost. Tip merge is cheaper when the tip is clean. Forcing selective promotion on a trunk-based team that deploys main continuously may be the wrong shape; match the model to how many unfinished features actually share a long-lived env branch. Also do not copy "cherry-pick forever" without shrinking trains; hell at scale is a design smell, not a badge of rigor.

Fabric CI/CD: How Do You Limit Blast Radius Across Dev Workspaces? (deployer reconcile set vs git change set)
Variable Library: How Do You Switch Active Value Sets from Dev to Prod? (stage remap beside git promotion)

Sources (community grounding): Fabric CICD branch promotion strategy: merge or cherry-pick, plus Microsoft Learn Fabric CI/CD / fabric-cicd git-flow guidance for environment branches and promotion.

Name the commits. Cut the temp branch. Open the PR. Then deploy. The tip is not a release note.