User experience challenge: Installing GitLab

Yesterday I joined the UX group conversation and we had a look into the installation page for GitLab. The order was misaligned, with making Raspberry Pi the number one distribution for running GitLab. Well, of course you can run it there - this is more of a psychological thing that your brain picks the first offered choice.

My colleagues were super fast with aligning, so I had a deeper look into the general "first impression" - you are now invited to follow my journey 🦊

First impression to get started

Let's have a look together on the following screenshot:

The first entry on the left seems to be a recommendation, don't you think? Let's just pick Ubuntu. Then there is a certain version being listed. Hmmmm, "16.04 LTS and 18.04 LTS". Which one should we pick now, no idea about the difference. Ok, let's pick Ubuntu 16.04 LTS and spin up a VM at our cloud provider. After a while, GitLab is running on Ubuntu 16.04 LTS.

In a couple of month or years, you'll have a maintenance task: The Linux distribution you had chosen from the website is End-Of-Life and you need to do heavy distribution upgrades, with downtimes of your production environment.

Why did the GitLab team recommend Ubuntu, and then list the old version first? Strange.

Let's iterate on this situation you just virtually visited.

• If you are an experienced administrator/SRE/engineer, you will already know and have your preferred distribution flavours.
• If you are new to installing GitLab, just because you've found out that GitLab is more than just a Git repository hosting system, you likely need a recommendation.

A little help from a friend

Let's assume that a friend of yours said: "I can help you with CentOS.". We'll visit the website again:

The first entry you'll recognise is CentOS 6 in the first row. Awesome, let's spin up a CentOS 6 VM and install GitLab!

Some time passes by, your server is running smooth with GitLab, you'll do the GitLab updates, and continue creating awesome software projects with CI/CD pipelines. At some point, someone hacks your server and steals your data.

After solving the business critical tasks, you'll do a post mortem on the incident. There you'll learn that CentOS 6 was end-of-life since 2 years, no more security updates for the operating system, and likewise, GitLab did not provide updated packages either. There was this one API security bug where the attacker could exploit your entire system and data.

Oh, snap. Why did CentOS 6 go EOL so fast? Ok, actually, there is CentOS 8 already which would have lasted a bit longer, actually some years.

Why didn't the GitLab team recommend to use this distribution instead?

Note: The above situation could happen in unmaintained environments. Also, maintenance and upgrades should always be considered, this is not delayed or replaced by using a modern Linux distribution. Make sure to subscribe to the GitLab (security) newsletter to stay up-to-date too!

A little help from GitLab

While our brain typically sees numbers in an ascending order and feels good about it, software versions require us to think in the reversed order: The newest versions provide us with the newest features and are a good thing for starters.

Let's imagine that the GitLab team has thought about this already, and have a look at the website again:

Now, you'll join your friend with a freshly spun up CentOS 8 VM and GitLab greets you for the next couple of years.

Or you have gone with Ubuntu 18.04 LTS by yourself. And if your brain tends to look into the middle of a web page, you might have picked Debian 10 instead of Debian 8.

More iterations

It is not perfect yet, and you'll likely have an idea in your head right now. Why not get into editing the installation page and suggesting an iteration in a merge request? Maybe we could combine CentOS 8, 7, 6 into one ... or we could swap OpenSuSE with SLES.

What do you think? In case you cannot start with a merge request, please open a new issue. Everyone can contribute - thanks!