We won’t be using Gitlab in the near future
We are bootstrapping our MVP, and have been looking for a devops solution for a while now. We’re a tiny startup, and hiring DevOps is notoriously hard, so when I found Gitlab Auto Devops (released this June), I thought this could be the solution to everything we needed.
Gitlab is an open source “alternative to Github”, which is so much more. It reimagines the scope of DevOps tooling to include developers, operations, and security teams in one single application.”. At Titan we dig open source, and we had a real DevOps pain to solve, so we explored Gitlab in the last couple of months as a potential solution. It failed.
I am impressed with the product vision, scope and velocity that the Gitlab team is making, and think it might come out a strong leader in the future — but right now we found it simply not ready for production for our needs.
The first thing we did is a quick and dirty pilot of a proof of concept app solving the Towers of Hanoi problem. The point was to write a simple app and bring it from git init to production as soon as possible. It took me about half a day to bring it to “almost production”, using Google Kubernetes Engine … which is quite good timing despite the occasional bug I ran into. Making the next leap from “almost production” into actual live production server accessible via an external DNS proved difficult or impossible.
Despite opening numerous issues on the various Gitlab issue trackers, consulting with their support team, and even hiring a “Gitlab expert” freelancer to assist us with the implementation, this toy project never reached production. In all fairness, after the initial test on GKE, we switched to trying out Amazon Elastic Kubernetes Engine, because our actual production environment uses AWS (we tried GKE initially because it’s setup is indeed easier). Even though EKS is more of a pain to set up than GKE, we expected things to go smoother … but the tech isn’t quite ready yet.
Just to give you one example — even if we would have deployed our toy project to GKE, the immediate next step would be to deploy a real system that includes a database, and database migrations. Gitlab Auto Devops currently does not support database migrations (some support will be added in the next version 11.4). This is just so bleeding edge right now, and we got cut by that edge. Luckily we found a kick-ass Devops freelancer who’s helping us bootstrap our infrastructure using non-Gitlab tools just in time for our first MVP release (coming soon… stay tuned!)
Another major pain we had was Gitlab’s issue management tools. When we first started, we tried using Jira for a few hours, decided it’s too complicated for us, and moved to Trello, which worked fine for a short time. When we outgrew Trello and wanted a more feature-rich system, and because we were already evaluating Gitlab, we tried Gitlab for our issue tracking — and it was a PITA. The Gitlab issue tracking system is just not fully baked. The UX is the opposite of slick, full of bugs, and just not convenient to use (certainly compared to Trello which we ❤️). I don’t know yet which system we’ll migrate to from Gitlab issues (we are currently evaluating a few options), but we definitely need something better. Oh, and to top it all — when our Premium trial (which they kindly extended multiple times!) ended, Gitlab hides all the story points you’ve previously entered because story points are a premium feature. They don’t just block you from updating SPs on stories — they hide information that you’ve previously typed in until you pay, which in my book is just not kosher.
To summarize: Despite everything above, I do ❤️ Gitlab as well … but it needs to mature a bit to be really useful to a startup such as ours.
