Faster upgrades on our Heptapod instances

The goal: catching up on GitLab base versions

Since the inception of Heptapod, first as a prototype, the version of GitLab upon which it is based has not been significantly updated, still being at 10.1. Now that Heptapod is gaining more traction, it's really time to do something about that.

In parallel with the Heptapod 0.6 series, some preparation work has been done to help us rebase Heptapod easily onto more recent GitLab versions, and we made successful experiments to jump to 10.2, then 10.3.

Side note: it's really satisfying that fat merge commits can not only be done in topics, but also that rebasing them works like a charm. There's something to be said for developers tackling the general cases by default.

GitLab 10.2 has already been merged in the main Heptapod branch. We'd like to push it further to 10.3 for Heptapod 0.7.

Testing strategy

While that doesn't sound too ambitious, one has to take into account that GitLab releases a minor version, such as 10.2.0, 10.3.0 every month. To state the obvious, we have to go significantly faster than that to catch up.

There is no way the Heptapod developers can test all the changes in a typical GitLab minor version. For example, the changelog of 10.3.0 mentions has 127 entries. Instead, we'll have to rely on:

• targetting the latest stable version of each series. This is what we've already done, with GitLab 10.2.8 and 10.3.9.
• GitLab's own QA. For changes that have nothing with repositories themselves, this should be enough.
• our functional test suite, that guarantees that Mercurial centric features do work.
• dog fooding and community testing. This is how we'll catch issues in the interaction with Mercurial and GitLab that aren't covered yet by the various automatic testing systems.

Upgrade policy

Starting with intermediate versions before Heptapod 0.7,

• the latest Docker image will be updated regularly with a new minor GitLab version.
• all instances managed by Octobus will be upgraded in the following few days
• only minimal manual testing will happen before the instance upgrades.
• the instance upgrade rate can be as high as weekly.
• upgrades of internal Octobus instances will happen on Mondays.
• upgrades of https://dev.heptapod.net will happen on Tuesdays.
• all instance upgrades will be announced at least 4 hours in advance.

To all these instance users: please report issues on https://dev.heptapod.net, including the exact Heptapod revison, as can be read on the help page. Here's an example

We still have a long way to go, and we're just ramping up, but the more we'll move forward, the easier it will get, because Heptapod will benefit from its own improvements.