Why would a GitHub employee go work at GitLab? Here are three reasons you should consider GitLab over GitHub for your DevOps Platform.

It has been an amazing first two months at GitLab. During my onboarding, I’ve dedicated some serious time to learning more about our DevOps Platform. I have talked to the open source community, prospects, and customers who I know demand the best when it comes to purchasing a product off-the-shelf. So I put the platform through its paces to see if it can deliver on their requirements.?

Here are some of the results:

(1) Individual Component Configuration Allows For Impressive Performance and Scalability

I was at GitHub for 4.5 years. I remember talking to prospects about running GitHub Enterprise from a VM (virtual machine) and many people were skeptical.? In the early days, it could only support 2,000 users, then it was 5,000 users, then we had a few that were hitting 10,000 users before I left in 2019.? I remember competing against the Omnibus installer from GitLab and only seeing things from a GitHub point of view.??

I never understood why someone would ever want to fine tune the VM from GitHub -- I figured they should trust them as the experts, and just use the base configuration that was already tuned for the most discriminating of customers.?

I know there are a lot of people out there with more experience than me about how to optimize the GitLab DevOps Platform based on specific project requirements.? I've learned there are three ways you can deploy Gitaly for different use cases.??

For example:?

You have a heavily used project that contains a monorepo type architecture and thousands of branches per day are being created to simulate trunk based development.? With that project, you need to build on every push to evaluate every change for security reasons like secret storage, inclusion of unapproved libraries, static and dynamic code analysis as well as others.??

In a generic model where there is one storage location, trying to optimize for developer experience and operational efficiency would be very difficult.? In GitLab, you can have the project “root” setup as a clean room where all final builds take place.? You can map a dedicated Gitaly node that is tuned and optimized for full clones (i.e optimized for read) to allow for faster CI access to the code.? You can also fork this project and create a shared Gitaly cluster to leverage it’s HA/DR and Geo-location features to distribute that code closest to the development teams.??

With this approach, you can establish a developer experience that is quick to respond on a push, status, or fetch no matter where you are in the world and you can take advantage of any public cloud infrastructure to optimize the syncing of this data in near real-time.??

You may not be at the point where these two different deployment models are critical to your success, so the traditional omnibus installer where Gitaly is included as part of the installation might be your best route.??

The great thing about this model is the GitLab’s DevOps Platform has been designed to allow you to get up and running quickly, but over time as you need to increase performance, you can break the components apart to scale with your whole organization.

(2) You can simplify the security of projects while increasing collaboration

One of the biggest issues I had when I was at GitHub was the top-level organizational namespace or orgs (or organizations) for repositories.? Even as an employee at GitHub, there were thousands of repositories stored in this single namespace.? You could try to filter the repository list based on the name you thought it would be.? But, this never worked and you were forced to use the scoped search and try to find something that existed in that repository.? A lot of times this would lead to someone just creating another repository causing a fragmentation of ideas and less collaboration.? It was a mess.

At GitLab, part of my onboarding was to create a group.? I was thinking in the back of my mind… why would I have a group when it is just going to be me?? Then, I went to the docs and realized a group is not just a group of people, but it’s a grouping of all the things that went under that group like a portfolio of development resources.? This included subgroups, projects, templates, CI variables, and so much more.??

I now had a mental model I was familiar with!? This is just like the filesystem on my computer, so I can organize my source code projects in a way I am familiar with.?

That got me thinking about how the security model inside of organizations worked at GitHub since git itself does not provide any RBAC.? Could there be a better way? ?

Now, I can grant access at the top level group, say everyone inside the company.? Then inside the subgroups, I can break projects up.? I can have an infrastructure subgroup where everyone in the infrastructure team has full control, but the rest of the company only gets read access.? I can also follow an open source or innersource model to create maintainers, contributors, collaborators and consumers teams to make sure everyone can collaborate across projects.

This means that when someone has access, it’s not just limited to the group and subgroup scopes.? You can actually limit people to what they have access to inside of the projects inside those groups.??

Maybe you only want project members to have the ability to create issues, you can do that.? Let’s say we want to lock a file, like our node dependencies file, you can do that.? But getting to that level of granularity would be very difficult to manage at scale.??

That is where project templates can be used.? You can establish consistency across your company that allows teams to move from one project to another and they know the workflow and best practices around collaboration with other team members making it easier to onboard new developers while helping them to be productive, faster.

(3) The automation framework is truly end-to-end - if you want it to be.?

Usually, when you hear the terms CI and CD, you might immediately think about jobs and pipelines.? There are a lot of tools in the market that can do that.??

The real question is:?

How do you map your internal development process from agile project management to release orchestration while enforcing security and compliance inside a single automation framework?

The biggest thing in any automation framework is the ability to create workflows based on internal metadata and applying rules to that metadata. When you try to do this through external calls to third-party solutions the communication is usually two, one-way API calls.??

If you need to run a rule across the API result, then one of the products needs to have custom code written to interpret the result and decide if you want to perform a job or re-route to another job or workflow.? If this code is compiled and hidden from the end user, troubleshooting why a specific job or workflow is not executing is extremely painful for the person consuming the automation.??

You can improve these developer inefficiencies with GitLab because you have access to all of the metadata about the project from idea to release -- enforcing a software chain of custody.??

Throughout the development process, you can use the metadata to provide immediate feedback to a project manager, development team lead, operations manager and/or SRE about the current state of the project.? Leveraging the security model we discussed in the previous section, I can even have workflows that are owned by one team and get called by another one.??

And if something goes wrong, I could create an issue for a developer in the coding project and an issue for the infrastructure team and link them together to enforce dependencies across teams while enabling transparency to know where they are at.??

Things bring me to one of the coolest features I’ve come across: scoped labels.?

Imagine having a scoped label for something like qa::ready. This metadata could trigger a deployment of the latest artifact to the QA environment and open an issue inside the QA subgroups project that triggers an automated test and compiles a report that determines the value of the QA scoped label and calls the next workflow once that value has changed.??

You can see how powerful this becomes as the state inside your project and your project’s dependencies change and how the dependencies can trigger specific workflows. This allows everyone to know what the current status is of a current change to the code base, creating the ultimate change management solution.??

But wait, there’s more… This automation framework can execute on any operating system, including Z Series mainframes. It can run commands at a bare metal, VM, container or K8s pod level allowing you to grab metadata from anywhere inside your organization from builds to control planes.??

You can also create Runner Templates to provide reuse and leverage best practices.? You can even place labels on projects for compliance like ISO 9001 and it will automatically ensure that the right templates that map to ISO 9001 are included as part of your pipeline!

I know I’m just scratching the surface...

I’m sure some of you reading this are already using these features in GitLab and can share even more examples around how they can be used in other real world situations. If so, I want to hear about it! Share it below - we’re really big on documenting these things for our open source community.??

For those of you that haven’t heard of GitLab, or are interested in learning more about how it can be used inside your organization, feel free to contact me.