Canary releases for Electron applications

To ensure quality and stability, it’s common to release some features in advance to a limited user base. That way, new features can be tested and potentially be fixed before being released to the whole user base. Those untested features are packed in what is typically referred to as “beta builds” that users can chose to install or not and for which the release cycle is shorter.

Early on, we decided to apply this strategy to our Electron-based application, Station.

With Nuts channels

We use Nuts for Station’s release-server, so, at first, we simply leveraged the “channel” feature included in Nuts.

With Nuts, when you include a channel tag in the name of your release file (Station-0.1.0-beta-osx-x64.dmg for beta), the release is then served only on channel-specific URLs (/update/channel/beta). All that’s left to do is set up your appUpdater’s feedURL to install channel-specific releases according to the user’s choice. That way, when you publish a beta-tagged release, only users that chose to receive beta builds will receive the update.

We let users chose whether or not they receive beta versions of Station.

This worked fine at the beginning, but we ran into several limitations:

• at some point, we wanted to test very unstable features that risked potentially breaking down Station. These features couldn’t be included in beta builds as they would risk impacting a large part of our user-base. Moreover, we wanted to keep these very unstable builds limited to us in the event of such a disaster 😒
• we saw Nuts getting lost in version comparisons between channels, which resulted in nightmarish situations where user’s versions got unexpectedly downgraded
• we wanted to be able to easily use a stable version of Station side by side with an unstable version 1/ in case of a serious breakdown on the unstable version and 2/ to investigate bug reports on the stable version.

With an alternative build, called Canary

We inspired ourselves from the strategy behind Google Chrome Canary, a Chrome build that includes the newest features from Chrome. But, as indicated, the build can — and does — completely crash sometimes.

The Chrome team releases a new version of Chrome Canary every day and early-adopters can test this version of Chrome — at their own risk — and report quirks and bugs fresh out of the Chrome team’s hands.

Also, it runs as a separate application on your computer, so it can operate side by side with a stable version of Chrome without any interference

The name Canary stems from the saying “a canary in a coal mine.” Back in the mining days, miners would carry down canaries into the mine tunnels to detect deadly gases: if the canary died, miners would know something was wrong. In conclusion, if you care just as much for your users, a “Canary” version makes a lot of sense!

We applied the same principle to Station and made a Canary version of Station that includes very unstable features but that we distributed exclusively to the Station team and among our closest friends at eFounders. 😀 This version gets daily updates while the stable version is updated every week.

Station Canary (left) running side by side with Station (right)

Build a Canary version of an Electron application

The two versions, stable and Canary, share the same codebase and build system, the only differences lie in:

• Canary includes the latest additions
• the name of the app and the appId are different, which guarantees that the two apps remain isolated when running
• the app logo 😎
• the Canary version uses a separated Nuts server to fetch updates. We use a dedicated empty Github repository that holds the releases of Station Canary and on which Nuts is plugged.

To build Station, we use electron-builder. To configure the Canary build, we use an alternative configuration file of electron-builder sitting next to the regular configuration file for stable releases:

In the end, we build the Canary via a npm command defined as:

"make-canary": "build --config electron-builder-canary.yml"

Release with confidence, Canary has your back

We have used Station Canary to battle-test a perilous migration from localStorage to SQLite (we’ll talk about this in a coming story, stay tuned).

For a full week, we released a new version of Station Canary every day: the team tested it all day long as their primary workstation, reported bugs and feedbacks that were handled, fixed and released the following day, and so on.

At the end of that week we released this apriori perilous migration for all users with a lot more confidence. Our canary was happily singing in the mine, so there wasn’t any reason to overthink it! 💪🏽

This story was cooked with the entire Station team (Joel Charles, Mathieu Débit and Julien Berthomier). Don’t miss the opportunity to try the future of work and ask an early access on getstation.com — or read the story behind Station here.

If you liked this story, you might love working with us on Station. Don’t be shy: drop me an email at alexandre(at)getstation(dot)com and let’s chat! 🍺

Station over and out.