---
title: "Don't Trust the Green Deploy: Grep the Live File for Your Ticket Marker"
canonical: https://dxdev.com/blog/dont-trust-the-green-deploy-grep-the-live-file/
datePublished: 2026-04-10
---
My daily audit told me I'd written dozens of commits across a pile of repos. I'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 Classic-ASP app, all sharing one git history. They sit side by side on disk so I can run several at once, each pinned to a different branch, each with its own local IIS site for testing. When I 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 me as a perfectly even table:

| Repo | Commits |
|---|---:|
| clone-1 | 8 |
| clone-2 | 8 |
| clone-3 | 8 |
| ... | 8 |
| clone-N | 8 |

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, you're not looking at multiple repos of work, you're looking at 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 my 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 my fix in the file the server reads" are two different questions, and CI only ever answers the first one.

I learned this the day I 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 I almost moved on. The thing that stopped me was not trusting the green. I went and looked at the actual deployed file.

## The marker comment is a post-deploy assertion, not decoration

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 I could identify the deployed artifact without relying only on a dashboard:

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

That marker functioned as a needle I could look for in the deployed artifact. After a deploy, I used it as one direct check alongside the expected behavior and target environment. If the artifact did not contain the expected marker, I 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, "I committed it" is genuinely 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 I 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, not a 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 signal-commit count, CI green, or a command that exited successfully-answers 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-and behaves correctly in-the target environment.

## Related

- [The Dry-Run That Lied: When --dry-run and --apply Run Different Code Paths](dry-run-that-lied-different-code-path-from-apply): a preview can be useful without being equivalent to the production path
- [The Most Valuable Line in an Agent's Ruleset: Verify the Fix in the Browser Before Claiming It's Fixed](close-the-verify-loop-browser-cursor-rule): the user-visible complement to artifact-level verification