How to run a beta channel for your desktop app

Why does a desktop app need a beta channel?

A beta channel lets a build run on real customer machines before everyone gets it. Desktop apps meet hardware, drivers, antivirus tools and old settings files that no test lab fully covers. A few dozen volunteers on beta find those problems while the damage is still small and the fix reaches them quickly.

Web teams can roll a change back for every user in seconds. A desktop release is different: once a build lands on a PC, it stays there until the next update check. A bad build sent to everyone means every one of those PCs has to check again, download again and restart. Catching the problem on beta is far cheaper than cleaning it up in production.

A beta channel also gives your release a rhythm. Builds flow to beta often, production moves on a schedule you control, and the question "is this ready?" gets answered by evidence from real installs instead of a guess.

How does an installed app know which channel to follow?

Each installed copy asks the update server about one channel by name, or by a token that identifies the channel. The server answers with whatever build that channel currently points at. Most update systems decide the channel in one of three places: at install time, in a settings screen, or through a hidden switch for testers.

• Baked into the installer. You build a separate installer for beta and send it only to testers. Simple, and testers never have to type anything.
• A setting in the app. A "Join the beta" checkbox writes the channel name to local settings. Easy to opt in and out, but anyone can find it.
• A hidden override. A key combination or command-line flag lets a tester type a channel name and password, or paste a token. Good for internal QA.

Whichever you pick, store the choice where the background updater can read it too. A beta tester whose foreground app follows beta while the background check quietly follows production will end up on a random mix of builds.

Should a beta channel be public or private?

Make a beta channel private unless you want anyone to be able to opt in. A public channel answers anyone who knows its name. A private one demands a password or a token, so you decide who gets unfinished builds, and you can cut a single tester off without touching everyone else.

Tokens scale best. Give each tester group its own token, label it, and revoke it when the group is done. Store passwords and tokens on the server as hashes, never in plain text, and show a raw token only once.

Who should be on the beta channel?

Put people on beta who will notice problems and tell you about them, and whose work will not stop if a build misbehaves. That usually means your own team first, then friendly customers who asked for early access, then a slice of power users with varied hardware.

• Your own team and QA machines. They should run beta every day, not only when testing.
• Customers who asked for a fix. They have a reason to confirm it works on their setup.
• Variety over volume. Ten testers on different Windows versions, GPUs and security tools beat a hundred on identical laptops.
• Not your most cautious customers. Someone who cannot afford a broken morning belongs on production.

How do you promote a beta build to production?

Promote by pointing production at the exact build that beta tested. Do not rebuild from the same commit and ship the new output: a fresh compile can differ in compiler version, dependencies or signing, and then production runs something nobody tested. One build, two channels, a pointer change.

1. 1

   Create the beta channel

   Add a channel named beta next to production, and make it private. Decide whether testers get a password or one token per group.

2. 2

   Give testers a way in

   Either build an installer that targets the beta channel and send it only to testers, or have them switch an existing install to beta with the credential you gave them.

3. 3

   Ship every new build to beta first

   Assign each new build to beta as soon as it passes your automated checks. Write release notes so testers know what to try.

4. 4

   Watch it for a fixed period

   Pick a soak time that fits your release pace, for example a few days, and look at crash reports, install failures and tester messages before deciding.

5. 5

   Assign the same build to production

   Open the production channel and point it at the build beta has been running. Installed copies on production pick it up on their next check.

6. 6

   Keep the previous build in reach

   Note which build production pointed at before. If something goes wrong, rolling back is the same pointer change in the other direction.

For more on rolling back, see how to roll back a bad desktop release.

How do you collect feedback from beta testers?

Give beta testers one obvious place to report problems, and make every report carry the build number. A report that says "it crashed" is useless if you cannot tell which build crashed. Show the version in your app’s About box and ask testers to paste it.

• A feedback link inside your app that opens an email, a form or your issue tracker with the version pre-filled.
• Crash reporting wired into your own app, tagged with the channel, so beta crashes are not mixed with production ones.
• Release notes for each beta build, so testers know what changed and what to try first.
• A short check-in after the soak period: "Anything worse than the last build?" catches the problems nobody bothered to report.

Should feature branches get their own channels?

Per-branch channels help when testers need to try one feature in isolation. Each branch gets its own private channel, a CI job publishes every push to it, and a tester follows that one channel. The cost is clutter: branch channels pile up, so they need an owner and an expiry rule.

Keep beta for builds from your main line that are candidates for production. Use branch channels for "please try this one change" requests, and delete them when the branch merges. The GitHub Actions guide shows how the mapping from branch to channel works in CI.

How Omnihorn handles beta channels

In Omnihorn a channel is a pointer to one build. Every app starts with a production channel; you add beta on the Channels tab and choose public or private access. A private channel can use a password or channel tokens. Assigning a build to a channel is how you ship it, and assigning an older one is how you roll back.

• An installer per channel. On the Installer tab you build an installer for each channel. For a private channel, Omnihorn bakes a channel token into that installer, so testers install from beta without typing a credential.
• A hidden switch for testers. Shift+click on the version line at the bottom of the installer window opens a dialog where a tester enters a channel name and password, or a token.
• Promotion is a reassignment. Open the production channel and assign the build beta has been running. Builds are never changed after upload.
• Branch channels from CI. A push from a branch that no channel follows creates a private channel for that branch. Unused auto-created channels expire after a period that depends on your plan; you can keep one for good from the dashboard.

Omnihorn does not collect feedback about your own app for you, so plan your own feedback link and crash reporting. The number of channels per app depends on your plan; see pricing. Step-by-step instructions are in Channels and rollouts and QA testing.

Common beta channel pitfalls

• Leaving a tester stuck on an old build. When beta stops getting builds, testers fall behind production. Either keep beta moving or move testers back.
• Assuming a switch back to production is harmless. A tester who leaves beta may be handed an older build than the one installed. Make sure your app can read settings and data files written by a newer version, or warn testers before they switch.
• Sharing a beta installer that carries a token. Anyone who gets that file gets beta. Revoke the token if it leaks and build a new installer.
• Rebuilding for production. Ship the bytes you tested. A new compile is a new, untested build.
• No version in bug reports. Without the build number you cannot tell a regression from an old bug.