Distribution

On this page

Mission

Distribution ensures the experience of installing and maintaining GitLab is easy and safe for everyone. It is Distribution team's task to think about the widest variety of installation/update use-cases and provide a solution that will satisfy most needs. Distribution is there to provide the best possible experience for a user that is a novice but also a veteran when it comes to installing and maintaining software.

Vision

Distribution team vision is shown below, and not limited to:

Technology

Team

Team members

The following people are members of the Distribution Team:

Person Role
Marin Jankovski Engineering Manager, Distribution & Release Management
David 'DJ' Mountney Senior Software Engineer, Distribution
Jason Plum Senior Software Engineer, Distribution
Ian Baum Senior Software Engineer, Distribution
Balasankar "Balu" C Software Engineer, Distribution
Ahmad Hassan Software Engineer, Distribution
Robert Marshall Software Engineer, Distribution

Stable counterparts

The following members of other functional teams are our stable counterparts:

Person Role
Clement Ho Frontend Engineering Manager, Distribution, Monitor & Packaging
Simon Knox Frontend Engineer, Distribution

Team responsibility

Distribution team is responsible for:

  1. The installation, update, and upgrade pages.
  2. The omnibus-gitlab installation package.
    • Installation using package is simple, quick, secure and protects the data integrity.
  3. A cloud native installation method.
    • Installation using the Helm charts is able to scale easily with the increased demand.
  4. Build and own the infrastructure used for creating the various installation methods.
    • Provision and maintain GitLab CI runners used for making above mentioned installation methods.
  5. Ensure that GitLab can be installed for self-managed installations and GitLab.com.
  6. Maintaining infrastructure used for work.
  7. Triaging issues in all owned projects.
  8. Creating training sessions.

Team objectives

Based on team responsibilities, the following objectives apply:

Projects

Name Location Description
Omnibus GitLab gitlab-org/omnibus-gitlab Build Omnibus packages with HA support for LTS versions of all major Linux operating systems such as Ubuntu, Debian, CentOS/RHEL, OpenSUSE, SLES
Docker All in one GitLab image gitlab-org/omnibus-gitlab/docker Build Docker images for GitLab CE/EE based on the omnibus-gitlab package
GitLab Helm Chart charts/gitlab Cloud Native GitLab Helm Charts
Docker images for GitLab Helm Chart gitlab-org/build/CNG Individual images used by GitLab Helm Charts
GitLab Helm Chart operator gitlab-org/distribution/gitlab-operator Support project for GitLab Helm Charts, performing various tasks such as zero downtime upgrade
Kubernetes Helm Charts index charts/charts.gitlab.io Helm charts repository index
AWS images AWS marketplace AWS image based on the omnibus-gitlab package
Kubernetes helm charts Official Helm Charts Application definitions for Kubernetes Helm based on the omnibus-gitlab package
GitLab provisioner gitlab-org/distribution/gitlab-provisioner Creates a GitLab HA installation using Ansible and Terraform
GitLab PCF tile gitlab.com/gitlab-pivotal One click installation of GitLab in Pivotal Cloud Foundry based on the omnibus-gitlab package
GitLab Terraform configuration gitlab-terraform Terraform configuration for various cloud providers
Omnibus GitLab Builder GitLab Omnibus Builder Create environment containing build dependencies for the omnibus-gitlab package
Upgrade time metrics Upgrade time metrics page on GL Pages Stores the result of calculation of time needed for upgrade between versions in chart form. Backed by Google sheets. Hosted using GL Pages

Public by default

All work carried out by the Distribution team is public. Some exceptions apply:

Some of the team work is carried out on our development server at dev.gitlab.org. Infrastructure overview document lists the reasons.

Unless your work is related to the security, all other work is carried out in projects on GitLab.com. If you need to submit a sensitive issue, please use confidential issues.

If you are unsure whether something needs to remain private, check with the team Engineering Manager.

Onboarding and offboarding

In addition to general company on-boarding and off-boarding, Distribution team has its own process to get new team members up to speed more quickly.

If you are starting with your onboarding, open an issue in Distribution team issue tracker, select Team-onboarding template and assign the issue to yourself.

Going through the steps noted in the issue should be your top priority, higher than the general company on-boarding issue. This is because items in team on-boarding are specific to your role and it will allow you to get up-to-speed quicker.

Off-boarding should be carried out by the Engineering Manager of the team, using the appropriate issue template in the same issue tracker.

Work Resources

General resources available to developers are listed in the Engineering handbook.

In the Distribution team specifically, everyone should have access to the testground project on Google Cloud Platform. If you don't have access, ask the team lead by creating issue in Distribution team issue tracker and label it Access Request.

Infrastructure and maintenance

As part of the team responsibilities, team owns maintenance of infrastructure used for day to day work. For list of nodes and description of the maintenance tasks, see the infastructure and maintenance page.

Distribution Open Work Day

We set aside one day per month to work on pet projects that are improving GitLab. For more details, see open work day page.

How to work with Distribution

Everything that is done in GitLab will end up in the supported installation methods that are distributed to users. While that sounds like the last link in the chain, it is one of the most important ones. This means that informing the Distribution team of a change in an early stage is crucial for releasing your feature. While last minute changes are inevitable and can happen, we should strive to avoid them.

We expect every team to reach out to the Distribution team before scheduling a feature in an upcoming release in the following cases:

To sum up the above list:

If you need to do install, update, make, mkdir, mv, cp, chown, chmod, do compilation or configuration change in any part of GitLab stack, you need to reach out to the Distribution team for opinion as early as possible.

This will allow us to schedule appropriately the changes (if any) we have to make to the packages.

If a change is reported late in the release cycle or not reported at all, your feature/change might not be shipped within the release.

If you have any doubt whether your change will have an impact on the Distribution team, don't hesitate to ping us in your issue and we'll gladly help.