Get cozy at work
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 choose 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.
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:
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)
The two versions, stable and Canary, share the same codebase and build system, the only differences lie in:
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"
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 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.