Channel Partner Implementation Services

Implementing a GitLab instance

• Decide between GitLab Community and Enterprise Editions
  • First, you need to decide which edition of GitLab to install for your customer. You can find plenty of information about this below.
• Reference Architectures
  • Read, understand, and follow the guidance given in this reference architecture page. It’s crucially important for long term maintainability of a GitLab instance.
• GitLab Environment Toolkit GET
  • GET getting started video
  • This is the Way… to install GitLab. The GitLab Environment Toolkit (GET) is a set of opinionated Terraform and Ansible scripts to assist with deploying scaled self-managed GitLab environments following the Reference Architectures. Built and actively maintained by the Quality Enablement team.
• Other Installation Methods
  • Make sure any automation you provide that automatically installs GitLab is installing the Enterprise Edition, and leverages at the core one of these installation methodologies to have a supported configuration
• Unsupported Designs
  • Also review these unsupported configurations to make sure you are in compliance with our support requirements.
• Next Implementation Steps After Installation
  • Once you have the product installed, here are additional steps to make the installation operationally successful (like backups).
• Upgrading GitLab
  • Upgrades are important to become good at. GitLab schedules major releases for May each year, by default. GitLab releases a minor update on the 3rd Thursday of every month, and has released monthly consistently for more than a decade. Security patches are released more frequently. GitLab.com has updates multiple times per day.

Implementing GitLab Runners

• GitLab Runner Overview
  • GitLab Runners represent the largest workload the system generates. The Runner is the software that executes all of the CI pipelines. It’s possible to deploy them on fixed infrastructure, or autoscale them (up and down) in a cloud provider.
• GitLab Runner Installation
• GitLab Runner Advanced Configuration
• GitLab Runner Monitoring and GitLab Runner Fleet Dashboards

Deciding between GitLab Community and Enterprise Editions

GitLab has two distributions:

• Enterprise Edition (EE): built from the official GitLab repository. It contains the code of all license tiers, including the open-source code of Free and the proprietary code of Premium and Ultimate.

• Community Edition (CE): built from the open source fork of GitLab. It contains only the MIT licensed code from the EE repository above, synced with that one automatically on each push.

This means that both editions contain the exact same version of our Free features, but only EE contains Premium and Ultimate features.

Which one should I install for my customer?

Premium or Ultimate customers

No choice: you need to install EE.

Free customers

Rule of thumb: always go with EE, except when you can’t.

Upsides of installing EE:

1. No need to do a migration when your customer decides to upgrade to Premium or Ultimate.

2. Optionally get access to free Premium or Ultimate features through our Registration Features Program. You can find the list of those features here.

Then why would anybody go with CE?

There are some customers who are mandated to use open source tools that has a license compatible with their internal policies. Since CE is licensed under the extremely permissive MIT license, it can generally satisfy any of those requirements. Thus, the only reason to install CE is if the customer explicitly asks for it. Otherwise, start with EE: even if the customer decides not to share usage statistics with us, it’ll still be just a flick of a switch for them to upgrade to Premium or Ultimate later.