GitLab (Self-hosted)

Out-of-the-box Source Code Repository Integration

Introduction

:bulb:Early Access

This integration is in early access. To find more information about the release stages of our integrations, see Release Stages.

The LeanIX VSM GitLab Repository integration offers an easy way to auto-discover all your services from your on-premise GitLab Enterprise instance. Based on this VSM's mapping inbox allows you to easily sift through all the stale information from GitLab to decide, which services are really useful to your organization and hence should be part of your service catalog. This will help you to maintain a high standard of data quality when you subsequently map your services to their individual teams to create clear team ownership.

Integrate with GitLab Enterprise to:
  • Automatically discover your services to build your company-wide service catalog
  • Map team ownership to have clear software governance in place
  • Automatically get Change & Release events for your DORA metrics

Setup

The integration runs as a dockerized agent to continuously fetch your GitLab data and pass it into VSM. See the technical details on the project's page..

Configuration in GitLab & VSM

To set up the integration follow the below steps:

  1. Go to your VSM workspace > Settings > Integrations > GitLab and follow the setup guide

    1. You will need:
      1. Personal Access Token with the following scopes (see the GitLab documentation):
        1. api
        2. read_user
      2. The root GitLab group(s) you want to scan (e.g. acme)
      3. A callback URL of the broker once deployed on your estate. This is the address in your network the webhook events from GitLab will be sent to (e.g. https://acme.vsm-broker:8080). For more details on the different scan modes go to the technical documentation.
  2. On successful setup, you will receive an autogenerated docker command. Use this to deploy the broker in your infrastructure. On successful setup, you can return to the admin panel in VSM to check the status of the integration or start mapping repositories to services.

docker run --pull=always --restart=always \
           -p 8080:8080 \
           -e LEANIX_DOMAIN=<region>.leanix.net \
           -e LEANIX_TECHNICAL_USER_TOKEN=<technical_user-token>\
           -e GITLAB_TOKEN=<secret-gitlab-token> \
           -e GITLAB_URL=<GitLab base URL(https://gl.domain.com)> \
           -e GITLAB_WEBHOOK_URL= <https://acme.vsm-broker:8080> \
        leanixacrpublic.azurecr.io/vsm-gitlab-broker

Multi-group support

VSM allows you to scan multiple GitHub groups with the VSM GitLab broker.

You can either specify them on the initial setup. Or you can add further groups post-setup via the admin panel.

📘

Subgroups

GitLab allows for nested groups (i.e. subgroups). For instance acme/finance. The integration today only allows you to specify root groups (which will be scanned recursively for repositories) e.g. only acme would be a valid input.

The mapping inbox should allow you to distill the repos from subgroups and thereby make your mapping decisions.

Let us know if you believe the integration itself should have filtering options and what use cases you forsee.

Supported GitLab Releases

We support GitLab Releases >=15.

DORA Metrics

Software Delivery Metrics are the best way for teams to track and monitor team productivity. The GitLab repository integration can automatically fetch information for two of the most important DORA metrics:

  1. Deployment frequency: Number of deployments to production for a Team.
  2. Lead time for changes: Time from committing a change to code successfully running in production.

See the detailed guide on DORA metrics for what the prerequisites are.

Imported data

The integration retrieves the following pieces of information from your GitHub Enterprise instance:

  1. Metadata, such as repository name, description, URL, etc.
  2. Repository status e.g. archived, active
  3. Repository code composition e.g. typescript
  4. Repository topics e.g. frontend.
  5. Repository visibility e.g. private
  6. DORA metrics: Deployment frequency and Lead-time-for-changes