tldr;instead of now installing/using JIRA, Trello, Github, Jenkins/TravisCI, and Teamcity, I can just install one thing – Gitlab, spend a little time configuring it, and be ready to take your development process to the next 5 levels (if you’re not already there)

Gitlab 9.4 was just released and I’m pretty excited about it. A lot of stuff that Gitlab is doing is really showing that they value empowering developers and pushing ops in The Right Direction (tm) – for me that means towards automating deployment, and getting smarter about how we ship and test.

A little background on why I’m excited by Gitlab these days: I recently came across a characerization of developers into two basic camps – those who build iterate and those who obsessively plan then build. While I’d love to be (or at least say I am) both, in my own mind I can only imagine myself as 80% of the first (build & iterate) and 10% of the latter (obsessively plan then build) and about a 10% of “other”. While I spend time planning before any big feature (and even some small ones), I generally set a hard limit on planning to a few minutes or even a few hours (if the problem is really interesting and it takes me a while to grok it). This means usually when I’m thinking of a problem, I’m going through the rough breakdown of steps to solve it (starting with the naive, dumbest way, and progressing to more complex solutions) in my mind in the order of minutes, and will start working soon after that. This of course, is a double edged sword becuase it lets me ship faster, but also on very complex tasks can come back to bite me, and if I’m embedded in a deveopment team, it can lead to some conflicts with other developers’ notions of “production ready” code. While I could say a lot on why I don’t think this is entirely a bad thing, I don’t care enough to try to change your mind (if that’s even possible), so just’do you.

Regardless of whether you think developers should build and iterate or obsessively plan and build, it’s basically an absolute truth that adding the proper process to the development process will benefit both types of developers. Regardless of how much you plan, software you write will produce errors and will create technical debt, and depending on how fast you “build and iterate”, there will be bits that you overlook, or that cause issues. “Good process” to me is whateveer helps your developers overcome this, seemingly automatically, replacing discipline with automation.

The Golden Process (AKA Doing It Right (tm))

With my current knowledge of software deployment, a process that’s just about perfect (“golden”) looks like:

• Easy to organize ticketing and work planning
• Code linting/checking - ideally done automatically and gating commits/remote pushes
• Unit testing - ideally done automatically and gating commits/remote pushes, make sure individual functions/methods/statements work like you expect
• Integration testing - ideally done automatically and gating commits/remote pushes, make sure the larger bits and bobs in your system work together like you expect
• End to End/Acceptance - ideally done automatically on whatever manages deployments, make sure the application as a hole does whwat it is supposed to do, especially from a user’s standpoint
• Test Environment - ideally one-click, should be able to spin up a version of the app at any commit hash/stage of development
• Deploy - one click and your app is live/rolling out

With the right process, it is possible to get the best of both worlds – deliver fast and iterate AND introduce a minimal amount of errors. Of course, this doesn’t protect you from doing the fundamentally wrong thing to start with (incurring a large amount of technical debt), but it does keep you covered somewhat even in that case, because the testing you’re doing should make any large refactorings even easier. There’s no way to prevent refactorings or non-optimal code form being written, so the best you can do is make it easy on yourself to fix.

Why Gitlab’s changes are exciting

With my idea of what a golden process is, it should be obvious why I’m excited by what Gitlab is offering, both on Gitlab.com and when you self-host. It’s absolutely amazing that I can find a tool that does (or is trying) just about every step of the golden process, in one coherent package. Gitlabs auto deploy features and all the continuing work to integrate new features into Gitlab like boards (before Github) and chat powered by Mattermost are really great for individual/small groups of developers looking to do a lot without buying lots of different subscriptions to lots of different services.

That’s a huge point: instead of now installing/using JIRA, Trello, Github, Jenkins/TravisCI, and Teamcity, I can just install one thing – Gitlab (and spend some time configuring it).

Also, keep in mind that all of this is done 100% in the open. Gitlab is an open source project, and some competitors (cough Github cough) are not. While I’m no Stallman, I do get a certain fuzzy feeling when my open source software is hosted using a similarly open platform.

I have quite a record of building faith in new exciting technologies only to see them sort of fall off/completely die for business reasons (RethinkDB, FirefoxOS), but it looks like this time is different, and Gitlab is here to stay. It’s one of the very very few companies that I would work for full-time and actually give a fuck about (I’ll write out my thoughts on full-time employment some other time).

Why isn’t Gitlab the most popular repository provider right now?

That’s a good question – I think a lot of it has to do with the momentum that Github has, for trend-driven and non-trend-driven developers alike. Github has been around so long and has provided so much value (it is a great tool), that it has become a “neutral good” incumbent and there’s not much reason for others to replace it (especially since they’ve already gone through the trouble of setting up the numerous integrations they had to).

Most commonly, people site two problems with Gitlab:

1. UI/Navigation confusion (usually regarding difficulty to discern contextual areas/navigation, finding buttons/etc)

2. Slowness (usually referring to Gitlab.com

Both of these issues are actually being actively worked on by Gitlab, or aren’t even issues at all (number 2 is certainly not an issue especially if you self-host on a large-ish machine). I haven’t seen many other valid criticisms of the software, and I spend quite a bit of time in comments sections on sites that are known to be quite harsh/demanding of software (and where trolls abound too, I’m looking at you reddit/youtube). This leads me to believe it’s only a matter of time (barring some catastrophic business failure) until Gitlab starts to gain critical mass. If I could invest in Gitlalb, I would – that’s how strongly I feel about what they’re doing there. Of course, there are lots of other ways to contribute as well.

Suffice it to say I’m definitely a large fan of Gitlab and excited to see all the things they have coming in the future. It’s the combination of Good Enough (tm) components that makes a hacker like me extremely excited to see all the things it can do.