The Gitlab product: everything DevOps
Understanding GitLab means understanding DevOps, which is thankfully the subject of this recent Technically post. The norm – for sure at small to medium size companies – is that each part of the complicated DevOps workflow, from issue tracking to source control, requires a disparate tool.
Gitlab, though, provides tools for every step of the DevOps process, from issue tracking to monitoring. Their take is that you should be doing all of this in one, single tool to consolidate your stack. This comical visualization on their old homepage puts things into perspective:
Refresher: what’s DevOps?
Understanding GitLab means understanding DevOps, which is thankfully the subject of this recent Technically post. Here’s a quick refresher if you can’t be bothered to click.
Much of the tedious process of building software is actually what happens after you write working code: testing that code to make sure it’s going to work for your users, and then actually getting it out there into the wild, and monitoring it to make sure it’s performing well. These three pieces are often categorized as:
- CI, or Continuous Integration – testing your code frequently
- CD, or Continuous Deployment – deploying your code frequently
- APM, or Application Performance Monitoring – keeping an eye on your app’s performance
Imagine you’re an engineer building a new feature for your company. You get the code working on your laptop and acting as it’s supposed to. Now what? You’ve got two big steps left before your users can get a hold of it. First, you need to merge that code into the rest of the codebase, including testing it heavily across a few dimensions to make sure it doesn’t break anything. Second, you need to push that updated codebase to your application’s users. Finally, once it’s in the wild, you want to make sure it performs well and doesn’t break, for eternity.
This is basically what DevOps is, the operations of shipping software. And it’s really a cycle, since this process happens all the time:
A common “gotcha” when you hear the word “DevOps” – it could be referring to any number of permutations on the above idea: a philosophy, a series of tools, a process, you name it. The definition we’re using here relates to workflows and tooling, which is the one you need to understand GitLab.
GitLab’s philosophy: one stop shop
With that in mind, it’s pretty easy to understand what GitLab does – they provide tools for every step of the DevOps process, from issue tracking to monitoring.
The norm – for sure at small to medium size companies – is that each part of this DevOps workflow requires a disparate tool. A normal stack might look something like this:
