So GitLab is advertising that it's the one place to do the entire software development lifecycle. Are there any big shops that have converted to 100% (or almost 100%) GitLab? Out of the six big names they list on their website, the only one that they have a case study for is Thomson Reuters, and they used Jenkins for CI (and it's from 2017, so a lot of this other functionality wasn't built yet).
It's just a somewhat different strategy. Most of these tools (GitHub, Azure DevOps, Jira) only cover some of it (GitHub and ADO can both do deployments and code storage and ticketing, but not any of the monitoring stuff or security stuff, as an example), and even then people often bolt on whatever they like anyway. But with GitLab betting that people will pay more (a lot more if you want everything -- $99 per month), is anyone actually doing that at scale?
Because for $20 per user per month (the middle tier), I'd just spend the extra buck to get GitHub, given that the features in that tier are very similar (GitHub doesn't have complex issue management yet, but it's coming). Or maybe just do the Azure DevOps $6 per user per month plan and endure the whining from the devs :P.
My company (several thousand) uses GitLab for code, CI/CD (which has security and monitoring in some add-on YAMLs we have to include, not directly through GitLab), packages (python wheels, jars) and docker images, and we're slowly moving to GitLab for terraform and kubernetes integration. We plan to stay on JIRA, though.
It's hyperbole to say you can use it for the entire lifecycle. That might work fine for one-product monorepo shops, but Gitlab still doesn't scale well right now. Aside from basic issues like the runners not working well, the binary artifact repositories are way behind what something like Artifactory or Nexus offers. It's extremely annoying not having group and server scoped registry tokens except for the container registries. It makes it more difficult than it should be to publish modular libraries to be used elsewhere in your organization by other products. It's effectively unusable if you're working behind an air gap and trying to mirror public registries. The only way I can think to do it is creating a dummy projects with every kind of package registry enabled and push all of them into that one repo, but that won't work for things like Maven that have a notion of namespacing.
It can't really replace something like Jira, either (and in Platform One's case, it doesn't). You can only create an issue in a repo, but there is plenty of work organizations do and want to track and organize that can't be directly tied to a code change, let alone a code change in only one repo. So where do you raise an issue to track work not related to writing code or related to writing code but across multiple repos? I've seen people create dummy repos that serve no purpose except being a central place to put issues, but that is just working around the limitations. It's fine as a bug tracker, but not a general purpose work tracker and project management solution.
Also, in Jenkins' defense, it's often nice to have a general purpose automation server. I never liked Jenkins, but I miss being able to create jobs that check the health of your deployments, report filesystem usage to user of your developer workstations, run very large-scale end to end integration tests independently from builds, update wikis and documentation automatically. There is plenty of automation that can happen outside of code CI that may not be related to code changes at all but is still useful.
Understanding of course Gitlab does have a notion of scheduled jobs that just run on a timer rather than being triggers by a changeset push, but that still isn't enough, and embedding shell scripts in yaml strings is a very poor substitute for Jenkins' Groovy DSL when there is any kind of complicated logic required by your jobs.
Gitlab does have some features like rules and triggers that can do medium-ish complexity flows. Still not where Jenkins is, but there's some framework pieces there.
per the prospectus on page 16 the answer is definitely yes:
Net Dollar Retention Rate for customers who paid more than $100,000 in ARR is 283% as of 12 months ended January 2021 and 383% for YTD 2021, meaning this customer cohort increases on average the spent by 2.8x.
The highest net-dollar retention rate among all SaaS publicly-traded companies, whose average is around 120%.
I've been using ADO for the past year or two and I don't hate it. While it absolutely lacks features, and most ADO things have relatively tough to use UIs, it _is_ extremely fast compared to GitHub and has some amazing UI designs for a couple things (especially reviewing large PRs).
Although from what I heard they're porting the good parts into GitHub and deprecating/putting into maintenance mode ADO soon.
> Although from what I heard they're porting the good parts into GitHub and deprecating/putting into maintenance mode ADO soon.
Hush hush! By now that’s pretty much an open secret covered by various NDAs :)
What even the NDAs won’t tell you though is how much time ADO has before it’s fully “dead”. If Microsoft’s track-record is anything to go by, I would assume ADO customers will be “encouraged” to migrate 3-5 years from now, with at least another 5 before they start closing down, if not more.
Will be interesting to see how it plays out when the time comes.
I’m curious as to how the heck they’ll move the data over. ADO projects are made up of many git repos with a shared ticket setup and all of the links are configured that way. I have no idea where I’d even start with that.
I am not a big shop - I work on a team on the order of 10
We use GitLab as our "one place to do the entire software development lifecycle". It's a really good CI/CD runner in my opinion, the .gitlab-ci.yml files are expressive and enable reuse thru a pretty nice inheritance model, and integrating new service (container) builds is literally 4 lines of code to have every push build a new container and put it in GitLab container registry.
It also makes developing NPM packages a breeze, thru the same reuse of CICD files we can drop 4 lines into an JS/TS repo and have it publish to the built-in package registry on tags.
On top of this, its ticketing system is worlds better than GitHub's. Less clicks, more available relationships & tags, more views, inheritance/rollup via the group structures you can put in place let you view tickets at a repo / group level, and since you can create trees from the groups you can have reasonably expressive places to view groups of issues.
Finally - it's all free! We're using free tier self-hosted, and it's far superior to my experience with GitHub paid. I admit, we have decent (read: overscaled) hardware to self-host on, but GitLab really does offer a ton of useful tools to building software.
I will give a high-level overview. Essentially, it is a workflow runner. You can set up "jobs" in a "pipeline" (dependency graph of jobs), and each job is just a bit of yaml. This yaml has individual keys controlling things like running a script, configuring the environment, controlling the docker image executing the job, etc..
These jobs / yaml blobs can be included into other files / projects using another one of these keys, "including" another job/pipeline via configuring the path to the repo & path to the file you want to import. You can override any properties really easily on these includes as well. Anyways, my .gitlab-ci.yml for building a container (any repo containing a top-level Dockerfile works zero-config, non-top-level can be configured) looks like this
You don't even need to do that. Gitlab has repository configuration option to take CI config from another place. So you can have code only repo being built by a CI pipeline described elsewhere.
NPM Private registry doesn't really work for me with Yarn and NPM v7 when trying to run binaries. This is a major blocker for a lot of things.
Also the `npm install` is really flaky multiple times a day I get 404s for packages in the private registry. You need to keep retrying jobs that use that command until succeeds.
I experienced some initial configuration pain with their Package Registry, but after generating PATs for local use and passing secrets thru the CICD build runner nicely - and using yarn - I have had no issues publishing nor installing my own private modules.
Here are the commands I suggest you run to authenticate your local machine to GitLab:
yarn config set "@example:registry" "https://gitlab.example.com/api/v4/packages/npm/"
yarn config set //gitlab.example.com/api/v4/packages/npm/:_authToken "<your PAT here>"
yarn config set //gitlab.example.com/api/v4/projects/:_authToken "<your PAT here>"
When you need to debug, the output of
yarn config list
is pretty concise and helpful. Be aware there can be local per-config folder so if you have trouble in a specific project you should issue that command there and check for incorrect registry settings etc. I also suggest you fully commit to yarn or npm, they are definitely different enough to be awkward to combine.
> I also suggest you fully commit to yarn or npm, they are definitely different enough to be awkward to combine.
I can't even migrate to Yarn because of issues. Try using a package that has binary (`bin` in `package.json`) or other metadata and publish on your private NPM registry and then use it with Yarn or NPM v7 you won't be able to as it strips away this metadata.
For example, if I want to push a patched version of Playwright to my NPM registry. I can't use it if I don't use NPM v6. Also the daily 404s errors when trying to install your private NPM packages which requires retry your jobs isn't help either.
Sadly it's not an important enough issue for them to fix. I am really wondering if Gitlab is using their products themselves.
Intel was (is?) using it to some extent. I owned a repo from 2019 - 2020 and there was a big push/timeline of all the different repo services and their EOL/move to Gitlab. Unsure it that's still the case or if the new POR is GitHub, thought I heard whispers of that about to change before I left.
Anyways, I had to migrate like 100+ users into Gitlab and setup/babysit the CI/CD output of that repository (which is not software, just documentation but the build/release process is not trivial). I actually didn't have too bad of a time all things considered, and none of the problems described here. Unsure how much of that was use case or people above me keeping my life easy but I was a happy user.
Obligatory: My statements are my own and do not reflect the opinions of my employer. I'm not going to name that employer, but let's be honest, I can't stop you from figuring it out if you really want.
> Are there any big shops that have converted to 100% (or almost 100%) GitLab?
We use a combination of GitHub, GitLab, and Azure DevOps across the various SW Eng orgs in our company.
On GH, we split across both GitHub.com and internal GitHub Enterprise instances. There's been some shift to put everything on GH.com, but GH Actions for private repos are kind of busted, and it's really causing us problems. Staying on GHE is less painful for some of our orgs. Some teams use Jenkins instead of Actions, which is, as the kids say, "a whole mood".
Our GitLab-using orgs generally have tighter CD integration. As much as I prefer the GH UX, I have to admit GL has a much smaller gap between "I have an idea" and "my implementation is now CI-ed, CD-ed, and published to Artifactory".
Our ADO using orgs have an even smaller gap. Seriously. If you've never used ADO, you'd be impressed by how easy it is to get a full build pipeline set up in minutes. That is, as long as you stay on the garden path. These teams also have the hardest struggles when they stray off the path. (But my intuition here is that this isn't definitively an ADO problem and might actually come down to the skill sets of those teams.)
All told, we're several hundred engineers across these solutions. By my rough count, the total number using GitLab may be a hundred or so. They really like it, and it suits them very well.
(And before anyone says "omg why do you have so many solutions", the Eng efforts at our company are thoroughly distributed instead of consolidated. And, at least at an executive level, there's currently more faith in "right tool for the job" than in "alignment". For now.)
It's just a somewhat different strategy. Most of these tools (GitHub, Azure DevOps, Jira) only cover some of it (GitHub and ADO can both do deployments and code storage and ticketing, but not any of the monitoring stuff or security stuff, as an example), and even then people often bolt on whatever they like anyway. But with GitLab betting that people will pay more (a lot more if you want everything -- $99 per month), is anyone actually doing that at scale?
Because for $20 per user per month (the middle tier), I'd just spend the extra buck to get GitHub, given that the features in that tier are very similar (GitHub doesn't have complex issue management yet, but it's coming). Or maybe just do the Azure DevOps $6 per user per month plan and endure the whining from the devs :P.