Our daily audit told us we’d written dozens of commits across a pile of repos. We’d shipped one hotfix.

That number is a lie the way a hall of mirrors is a lie. Every one of those repos is a clone of the same legacy application, all sharing one git history. They sit side by side on disk so we can run several at once, each pinned to a different branch, each with its own local IIS site for testing. When we fix a bug and push, the fix SHA shows up verbatim in every clone’s log the next time they pull. So a single eight-commit day reads back to us as a perfectly even table:

RepoCommits
clone-18
clone-28
clone-38
…8
clone-N8

Eight, eight, eight, all the way down. The suspicious part is the evenness. Real independent work is lumpy. When every repo reports the identical count, the repos have not each done separate work. The count describes one history reflected many times. The audit tool counted reflections.

This is funny until you realize the same illusion governs the question that actually matters: is our fix live?

CI green means the pipeline ran, nothing more

In this deployment path, a build server reacted to a push and then promoted files toward a target environment. The team also had per-developer targets for branch-based staging. That made the deployment flexible, but it also created several distinct places where a green result could describe the wrong target for the question at hand.

The dashboard turns green. Green is seductive. Green is also answering a different question than the one in your head.

In this setup, green meant the pipeline ran to completion without an error. It did not by itself demonstrate that a specific change reached the file or artifact serving requests. In a mirrored multi-clone setup, green and the intended release could diverge in several ways:

  • You pushed from the wrong clone, and the branch you built wasn’t the one with the fix.
  • The build ran against a stale checkout that hadn’t pulled your commit yet.
  • The deploy target you watched go green isn’t the target fronting live traffic.
  • The file shipped, but an older cached or alternate copy is the one actually being served.

None of those throw a red X. The pipeline did its job. The dashboard is telling the truth about the pipeline and saying nothing about your change. “Did the build succeed” and “is our fix in the file the server reads” are two different questions, and CI only ever answers the first one.

We learned this the day we shipped the eight commits. One of them was a hotfix to a rate-limiting check that had started false-positiving on legitimate users. After it built green we almost moved on. We stopped because we did not trust the green. We went and looked at the actual deployed file.

The marker comment is a post-deploy assertion

Here was the habit that cut through the mirror illusion in this codebase: when appropriate, a change carried a traceable marker near the affected code or in the build metadata, so we could identify the deployed artifact without relying only on a dashboard:

' ITEM-XXXX: skip the false-positive path for internal navigation requests

That marker functioned as a needle we could look for in the deployed artifact. After a deploy, we used it as one direct check alongside the expected behavior and target environment. If the artifact did not contain the expected marker, we treated the release as unresolved and investigated branch, target, or stale-build state before calling the issue fixed.

The marker was a contract between the author of a change and the person verifying its release. It turned a fuzzy “should be live by now” into an artifact-level check. In systems that can surface a build version, release identifier, or a behavior-level probe more cleanly, those are often better verification signals than adding a comment solely for deployment.

This matters more in the mirrored setup than it would in a single repo. With multiple clones, “we committed it” is ambiguous about where. The fix can be sitting in one clone’s working tree, pushed from the wrong branch, merged but not deployed, or deployed to the wrong target. A commit existing somewhere is not the change being live. An artifact marker, release identifier, or behavior-level probe cuts through that ambiguity because it asks whether the intended change reached the target environment.

The rule we carried forward is that “fixed” requires deployed evidence. Code written and pipeline green are useful milestones, but the final check must confirm the intended artifact, configuration, or behavior in the target environment.

And then there’s the stuff with no git trail at all

The marker habit assumes your change lands in a file you can grep. Stored procedures break that assumption, and they break it badly.

Some changes in this system, such as stored procedures, did not have the same source-control and deployment trail. That is a risk signal, and it is no reason to rely on an ad hoc production command. The stronger pattern is an auditable migration or controlled change record, a defined rollback path, and an explicit verification of the intended schema, procedure version, and behavior after the change.

That is the out-of-band counterpart to artifact verification. Source, database, and configuration changes each need evidence appropriate to their delivery mechanism. The convenient signals (commit count, CI green, or a command that exited successfully) answer an easier question than the one a release decision actually needs.

A deployment dashboard can tell you the pipeline ran. It cannot replace evidence that the intended change reached the target environment and behaves correctly there.

Takeaway

A green deployment shows that a pipeline finished. It does not show that a specific fix is in the file or behavior your customers are hitting. Before calling a fix done, ask for artifact-level evidence, such as a marker in the deployed file, a release identifier, or a behavior check in the target environment. For database changes with no source trail, ask for a controlled change record, a rollback path and a post-change verification.