Headset Deployment Tool

Getting a large VR application onto a headset is a deceptively awful problem, and it gets worse the further it happens from the people who built it. I wrote a desktop tool to make the whole process boring.

The problem

Builds were distributed through general-purpose cloud file storage, which was never designed for this. It was slow, downloads broke silently, and there was no guarantee the file that arrived was the file that was sent. Versioning was a matter of naming conventions and hope.

The bigger issue was who ends up doing the deployment. Often it is a client, not an engineer, following written instructions on their own machine. Put the file in the wrong directory and the application fails in a way that gives them no useful signal about why. That is how a deployment turns into half a wasted day and a support call, and it is not a reasonable thing to ask of someone whose job is not software.

• Downloads failed or truncated without saying so, and the corruption only surfaced once it was already on a headset.
• Files placed in the wrong location broke the install, with no clear error explaining what had gone wrong.
• Every headset in a batch re-downloaded everything, so preparing a room of devices meant paying the transfer cost over and over.
• An interrupted transfer meant starting again from nothing.
• Knowing which build a given headset was actually running was harder than it should have been.

What it does

• Pulls current builds automatically from a single source of truth over a CDN, rather than relying on a manually maintained file share.
• Verifies every file as it arrives, so a bad transfer is caught on the operator's machine instead of on a headset in front of a client.
• Caches builds locally, so the second and subsequent headsets in a batch transfer from disk rather than re-downloading.
• Queries what is already installed on the connected headset and transfers only what is missing or out of date.
• Shows a plan of exactly what it intends to change before it changes anything.
• Resumes from where it stopped if a cable is pulled or a connection drops.
• Re-verifies the payload on the headset once the transfer completes.
• Uses access keys to control which applications and modules a given user can see, so the same tool serves both internal staff and clients with scoped visibility.

Builds for both Windows and macOS from one codebase.

What I took from it

This is the least glamorous thing I have built and possibly the most useful. Nearly all of the work is in the failure paths: what happens when the network drops, when a file is truncated, when the device already has a half-installed version. Designing so that every operation is verifiable and resumable, and so the destructive step is always previewed before it runs, is a different discipline from gameplay code and a genuinely valuable one.

The design principle throughout was to remove the opportunity for the mistake rather than document how to avoid it. If a file can be put in the wrong place, eventually it will be, and no amount of written instruction fixes that. The tool decides where things go, checks that they arrived intact, and tells the operator plainly what state the device is in.

It also moved me further into release and distribution engineering, which is the part of shipping software that students rarely see and employers consistently need.