Sharing Builds with QA — What Has to Travel Alongside the Binary

In the piece on tickets closed as "can't reproduce", one of the three root causes was environment drift — specifically, the build QA saw and the build the developer is reproducing against being two different binaries. This post digs into that one point. When you hand a build to QA, what has to travel with the file besides the file itself.

"Which build was this?" is already a failure

The first thing a developer needs when opening a ticket isn't the repro steps — it's which build the bug happened on. When that's missing, the developer has to ask, QA has to dig up yesterday's link, and if that link has since been overwritten with today's build, there's no way to answer precisely. That round trip adds time to reproduction. Unless the build identifier ends up in the report automatically, "which build was this" gets asked on every single ticket.

What has to travel with the build

The identifier and changelog help QA decide what to test. A known-issues list can also reduce duplicate reports of bugs the team already knows about. The two log-related items are separate problems. Where to find logs is something we've already mapped out by OS and platform — send QA that link. Retrieval is a different matter: the longer it takes to find, zip, and upload a log, the easier it is to leave it out. Shortening the procedure helps more than adding documentation alone.

The build identifier belongs on screen

If the identifier only lives in a doc or a release note, QA has to go find it and copy it in at the moment they write the report — and that step gets skipped constantly. Put it in a corner of the screen instead, and a single screenshot carries the build identity with it automatically.

// Bake version + commit hash into the build and surface them on screen
public static class BuildIdentity
{
    // Reuse PlayerSettings' bundleVersion as-is
    public static string Version => Application.version;

    // The commit hash is a placeholder the CI build script substitutes
    // (e.g. run `git rev-parse --short HEAD` and sed it in right before building)
    public const string CommitHash = "__COMMIT_HASH__";

    public static string Label => $"{Version} ({CommitHash})";
}

#if DEVELOPMENT_BUILD || QA_BUILD
public class BuildIdentityOverlay : MonoBehaviour
{
    void OnGUI() => GUI.Label(new Rect(8, Screen.height - 24, 400, 24), BuildIdentity.Label);
}
#endif

The point is substituting a placeholder like CommitHash for a real value inside the build pipeline. Relying on someone manually bumping a version number is a step that eventually gets forgotten. With the commit hash included, you can also tell apart "same version number, different binary" cases — a hotfix rebuild, for example.

Delivery method comes down to whether updates get noticed

Whether it's a shared folder, an internal distribution tool, or a store test track, there's one question that matters more than the choice itself — can QA tell when a new build has landed? Notification behavior and setup vary by tool, so verify that QA actually receives the version and change information when a build is published. Noticing updates matters more than the mechanism. No matter how carefully a build is put together, if QA never finds out it exists, it might as well not have shipped yet.

Wrapping up

Handing off a build isn't a file transfer — it's a context transfer. A build missing the identifier, changelog, known issues, and log retrieval path is functionally the same as telling QA to go figure it out. Pulling this context together costs a few minutes at most; the back-and-forth of asking, digging, and re-answering when it's missing costs far more. Even with all that context in place, there's one setting that's still easy to overlook: the Development Build checkbox. What it actually turns on and off in a QA build is the subject of the next post.

Hotkey-captured reports from Rekon automatically include runtime context such as the Unity version, app version, scene, and device. That context should not be assumed to uniquely identify a commit or rebuild. For precise tracking, also surface your team's build identifier, such as a commit hash, as in the example above.