As most of you may be aware of, the osu! build system got a lot more advanced earlier this year with the introduction of Release Streams. The basic idea behind these is that we can have multiple streams of osu! clients, allowing users to choose how close to the edge of their seat they wish to sit. While from time-to-time we have added and removed temporary testing streams (for things like testing a new experimental framework), there are generally three release streams available at all times:

Stable

The default release stream. Stable builds are generally, as their name implies, stable. There shouldn’t be any new bugs that find their way into these releases (in theory!). Stable builds are released as often as possible, but generally this ends up being between 1-8 weeks between releases. My personal aim is one release a month, but depending on the state of code and how deep in shit we are, this sometimes is not possible.

Beta

Beta releases are a mid-ground, offering inquisitive users early access to new features and fixes that are in the pipeline, without the possibility of the world falling apart on them. The beta release stream is safe for anyone willing to report bugs they may find, rather than raging about it.

If you don’t mind helping, please stay on the Beta stream. The more people we have testing this, the less chance bugs will find their way into stable releases, affecting the masses.

Beta releases happen every Friday automatically, or sooner if we decide there’s a need to get a hot-fix out to users rapidly.

Cutting-Edge

This is where things get interesting. You’ll be exposed to changes made to the osu! code-base in real-time. If we fuck up, it could fuck your osu! up badly. But you’re already here so you know these risks, right?! In exchange for the extra risks, we will give you our ears 24/7 and work with you to fix any issues you come across. You will also get access to some preview features that aren’t quite ready for prime-time, such as the Target Practice mod, the ability to fast-forward replays at varying speeds and more to come.

Cutting edge releases happen as we make changes, multiple times a day. We won’t force you to come join us on the edge, but we do appreciate those who do!

But How?

So… how do these streams work internally? We use git for source control, with two main branches of code: one for development (master) and one for stable releases (release). When any osu!dev makes changes, they first create a new branch of their own to isolate their changes. Once they are happy with what they’ve done, and want to share it with the team, they will submit a pull request. This is basically a way of saying “Hey, I’m ready for you guys to come check my code out!”.

Once at least one other osu!dev has reviewed a pull request, it is merged into the master branch. For those unfamiliar with the term “merge”, this basically means the code is moved from the developer’s private branch into the development branch, and considered to be finalised. The pull request and the master branch become one, and the pull request is destroyed.

Every time a pull request is successfully merged into master, a cutting-edge release is triggered by the build server (we use teamcity for .NET, buildkite for everything else). And that’s all there is to cutting edge releases!

Beta and stable releases are a slightly different story. As we don’t want to push either of these out until changes have had a while to simmer with cutting-edge testers and devs alike, it is up to me to decide when to merge master into release. Even then, performing the merge alone doesn’t do anything; it just prepares the changes for future distribution.

Both the Beta and Stable release streams are based on the release branch; the only difference is their triggers. Beta, as mentioned before, will trigger automatically every Friday. This is to space the builds out evenly and ensure users are not bombarded with constant updates. Stable releases are completely manual, and only triggered when I am completely happy with the state of the release branch.

If all this seems very complex, just thing of the three streams as a way of filtering out bugs from the majority of users. Cutting-Edge users get hit by most of them, and they are fixed before they hit Beta. Beta users (a larger user base) then get to confirm that we have actually covered all bases. Assuming beta users don’t find any issues, everyone is happy and we go ahead with a stable. Should any issues be found, it’s back to cutting-edge for a round of bug fixes!

I attempted to sum all this up into a pretty diagram. Click for full size!

There’s a lot more complexity not covered in this article that I will share in the future!

Automating deployment makes us very productive. The ability to push fixes out with just two clicks and having it completely integrated into our existing git/github workflows is really efficient and just doesn’t get old :).