In my day job as an Alliance Solutions Architect with GitLab, I often get asked, “How do we integrate X with GitLab?”
GitLab is a DevSecOps platform, for many organizations it’s the foundation that their entire development process is built on; rather than having to login to several different systems to manage, observe and advance this process, they benefit from one application to serve as the system of record. That said, GitLab can’t do it all, so there’s an opportunity to augment the platform and create more business value by integrating with 3rd party software and systems to maintain a unified experience for stakeholders, developers, and operators.
X could be a cloud provider, point tool, legacy application or web service that might be used in the dev cycle.
I wish I had a simple answer to this, but my first response is, “That depends on what’s being integrated.”
As I see it there are four facets of integration with GitLab:
- Use GitLab to deploy client applications to X / Host GitLab runners on X
- Host GitLab Server on X
- Integrate with the development cycle
- Deep GitLab application integration
1. Use GitLab to deploy client applications to X or Host GitLab runners on X
A very common use case and typically the easiest to achieve. This is a common ask of platform providers, who want to make it easy for their users to run apps built with GitLab on their infrastructure or application server. The path is to have GitLab server be able to authenticate to the hosting platform, and deploy the (ideally containerized) application to the platform.
A close cousin of this is the need to deploy GitLab runners to the infrastructure and register them with your GitLab instance, be it GitLab.com or a self-managed instance. Runners are easy to setup and register, and can be configured and scaled in many different ways.
2. Host GitLab Server on X
Another common use case for platform providers is hosting GitLab Server on their infrastructure. What makes this easy is GitLab runs almost anywhere; if you’ve got Linux, you can run GitLab Server (even on a Raspberry Pi). The work has already been done for the major cloud providers like GCP, AWS, Azure, Oracle Cloud, etc; and if you want to run on your own infrastructure, the Omnibus installer does most of the heavy lifting for you; it’s the easiest way to self-host GitLab.
3. Integrate with the development cycle
Here’s where it starts to get a bit more involved. The good news is that GitLab has extensive APIs and webhooks that allow for listening for events and pushing and pulling data.
If the goal is to integrate with the CI/CD pipeline this can be done by creating a container image that encapsulates the application or scripts necessary and defining a job within the pipeline that uses this image to run the integration. It’s likely the integrated app produces some output that someone needs to review; displaying this output directly within the Merge Request elevates 3rd party data rather than something that has to be searched for in another system. Depending on the nature of the tool being integrated, it’s possible to show results and a security report, metrics report or artifact that can contain almost any type of data.
4. Deep GitLab application integration
This is the most complex since it requires an understanding of the architecture of the GitLab application, and how an outside service will interact with and support this architecture; an example of this would be a managed PostgresSQL or Redis service. There’s a potential risk of downtime if this type of integration goes wrong, so it’s important to test thoroughly in a production-like environment before considering it production-ready. Fortunately GitLab publishes several tools to do this; GitLab Performance Tool (GPT) provides an excellent way to measure and report on the performance of a GitLab instance under various usage scenarios, it’s counterpart GitLab Browser Performance Tool test the browser performance of various GitLab pages.