A release process for teams

How a release moves through Omnihorn

A build reaches users only when a channel points at it. Uploading a build changes nothing for installed copies. Assigning it to a channel does. That one rule is the base of every release process on Omnihorn: you control who gets a build by choosing which channel it is on.

• Build: one uploaded version of your app, stored as 1.4.0+build.42. Builds never change after upload. To fix something you upload a new build.
• Channel: a named stream such as production or beta that installed copies check. Each channel serves exactly one build to everyone on it.
• Private channel: a channel that needs a channel token or a password. Use private channels for testing.

There is no percentage rollout inside a channel. To ship to a small group first, put that group on its own channel. The channels guide covers channels in detail.

Roles in a workspace

Omnihorn has four member roles. Owner and admin can do the same things. Developer and viewer can do the day-to-day release work but not the account-level actions.

The viewer role is not read-only today. A viewer can assign builds to channels like a developer. If you need a strict separation between who builds and who ships, keep it as a process rule for now.

A release flow built from channels

Most teams do well with three stages: a private test channel, a beta channel and production. Each stage is a channel. Promoting a build means assigning the same build to the next channel. The files are never uploaded again.

1. 1

   Upload the build

   Upload from CI or drag the build folder into the dashboard (see Upload builds). Wait until its status is active. A build that fails verification never reaches any channel.

2. 2

   Ship it to a private test channel

   From CI, a push to a branch that no channel follows creates a private channel named after the branch. You can also create a private channel such as qa by hand and assign the build to it. Testers install the installer built for that channel.

3. 3

   Test it

   QA runs the checks in Test a release before users get it: a clean install, an update from the previous version, and a rollback.

4. 4

   Promote it to beta

   Open the beta channel and assign the same build. Everyone on beta gets it on their next update check. Watch the Failed installs figure on the app’s Analytics tab.

5. 5

   Promote it to production

   When the agreed sign-off is in, assign the build to production. Write the release notes on the build first: the installer shows them before an update.

If you upload from CI, a channel can follow a branch. For example, beta can follow main, so every merge goes to beta by itself. Keep production manual, so a person always makes the last step. The CI/CD guide explains following branches.

Approvals are a habit, not a feature

Omnihorn has no approval workflow. Nothing stops a member with access from assigning a build to production. Agree on the rule outside the tool and write it down. A simple version that works:

• Only the release manager assigns builds to production.
• A build goes to production only after it has been on beta for an agreed time with no new failures.
• QA records the build number they signed off, such as 1.4.0+build.42, in the release ticket. The release manager assigns exactly that build.
• Production never follows a branch.

Plan your rollback before you need it

To roll back, open the channel and assign the previous good build. Installed copies treat any version that differs from theirs as an update, so the older build installs on their next check. No new upload and no new installer is needed.

• Pin the last good build. Pinned builds, builds live on a channel and the newest builds of an app are protected from automatic cleanup. Pin the previous production build before each release so it is there when you need it.
• Stop CI from moving the channel. A channel that follows a branch takes the next matching push, which would replace your rollback. During an incident, stop following the branch or pause the pipeline.
• Know your delay. Installed copies pick up a change at their next update check. How often they check is set per channel. Opening the app’s installer window checks at once.

The blog post How to roll back a bad desktop release walks through an incident step by step.

Release checklist

Who does what