The Distribution team is composed of two subgroups: Distribution:Build and Distribution:Deploy
Build team is focused on producing artifacts including system packages, container images, and related components like marketplace listings along with tooling required to create and maintain them.
Deploy team is focused on installation and upgrade mechanisms to ensure smooth deployments. This includes system integration, scripting, templating, and related configuration management tooling.
In addition to product deliverables, both groups review a large number of MR's authored outside the team. These include dependency and security updates along with configuration controls and other bundled components like PostgreSQL, Consul, Patroni.
The primary user persona for Distribution are system administrators who are responsible for managing GitLab instances. Team goals are to make it as easy as possible to deploy, upgrade and configure GitLab on a range of on-prem and cloud platforms at a variety of scales.
Deployments include everything from single node deployments for evaluating GitLab all the way through the 50K user reference architecture and beyond. The primary goal is to ensure end users have a high-speed, low-friction experience when managing GitLab with limited downtime or sevice disruptions.
Omnibus packages, Helm Charts and Operators are primary deployment methods Distribution currently supports.
Responsibilities:
Responsibilities:
Distribution team vision is shown below, and not limited to:
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.
Build team focus is ensuring GitLab components are tested, current, license compliant, and available for our users’ platforms and architectures. This group manages the build pipelines, researches support for new services, platforms, and architectures, as well as maintains existing ones. We strive to respond efficiently to build failures, security results, and dependency changes in order to ensure a safe reliable product for our users.
Deploy team focus is configuration, deployment, and operation of GitLab as a whole product. The goal is to deliver an intuitive, clear, and frictionless installation experience, followed by smooth, seamless upgrade and maintenance processes for deployments of any scale. We strive to deliver ongoing operational behaviors for scaling, little to zero downtime upgrades, and highly reliable experiences for not only instance administrators but their users.
Increase # of active installations
Reduce average days behind latest version
The following people are members of the Distribution:Build Team:
The following people are members of the Distribution:Deploy Team:
The following members of other functional teams are our stable counterparts:
| Person | Role |
|---|---|
| Grant Young | Staff Software Engineer in Test, Enablement:Distribution |
| Nailia Iskhakova | Senior Software Engineer in Test, Enablement:Distribution |
| Vishal Patel | Software Engineer in Test, Enablement:Distribution |
In addition to the separate responsibilities for Build and Deploy. The Distribution team as a whole is responsible for:
Based on team responsibilities, the following objectives apply:
Distribution and group::distribution label.omnibus-gitlab - This project creates platform-specific, self-contained GitLab packages and images for self-managed consumption in cloud environments and on-premisis hosting.
Cloud Native GitLab provides cloud native containers to deploy GitLab. These containers may be deployed and managed via Helm using GitLab Charts or GitLab Operator on Kubernetes, OpenShift, and Kubernetes compatible container platforms.
| 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 | gitlab-org/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 Operator | gitlab-org/cloud-native/gitlab-operator | The GitLab operator creates and manages GitLab instances/deployments in a container platform such as Openshift or Kubernetes. It will run an any environment that provides native Kubernetes resources including deployments, statefulsets, services, ingress/openshift routes, persistent volume claims, persistent volumes, etc. |
| Kubernetes Helm Charts index | charts/charts.gitlab.io | Helm charts repository index |
| AWS images | AWS marketplace | AWS image based on the omnibus-gitlab package |
| Reference Architecture Tester | gitlab-org/distribution/reference-architecture-tester | Spins up reference architecture based GitLab deployments using GET and runs QA against them |
| Omnibus GitLab Builder | GitLab Omnibus Builder | Create environment containing build dependencies for the omnibus-gitlab package |
| Licenses of bundled dependencies | Licenses page on GL Pages | Webpage listing the bundled dependencies in each package along with their license. |
The install and upgrade process is one of the first features that systems administrators experience when working with GitLab. As a result, the projects managed by the Distribution team have a high level of engagement by the user-base. The GitLab community is made up of more than just code contributors; users logging issues and feature requests are constantly pushing us forward and helping create a better experience.
In Distribution we strive for the following in our public projects:
The open core of GitLab is built on top of thousands of open source dependencies. These dependencies and their communities are important to the GitLab strategy, and working with these dependencies is an essential part of the projects the Distribution team maintains.
In Distribution we strive to:
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.
The team regularly publishes demos, discussions and meetings to these playlists:
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.
General resources available to developers are listed in the Sandbox cloud page.
In the Distribution team specifically, everyone should have access to the following resources:
testgroundcloud-nativeomnibus-build-runnerscloud-native EKS cluster for CI (requires a maintainer to grant access)If you don't have access to any of these resources, create an Access Request and assign it to your manager for approval.
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.
General engineering workflow applies to the Distribution team. Since Distribution is working across multiple projects, our team workflow is further explained and summarized on the Distribution workflow page.
The following important areas of the GitLab Handbook impact how we work and are worth reading.
Working all-remote and asynchronous first offer flexibility in how team members approach their workday. Team members must make choices on how best to balance work time with other areas of life.
For new team members, the following resources provide examples on how to focus their time:
The following GitLab Handbook areas are key in maintaining a healthy work/life balance.
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.
Create a Deliverables Request in the Distribution team issue tracker.
For requesting feedback you can ping @gitlab-org/distribution in your issue or merge request.
When looking for a Distribution reviewer for a merge request you should use the process outlined in our
merge request workflow for projects owned by the Distribution team. For
changes that need Distribution review outside those projects, please ping @gitlab-org/distribution in the merge
request.
There are occasions where the experise of the Distribution team may be needed in
support of a customer issue. When this does occur, the appropriate method of requesting
our engagement is by opening an issue on the Distribution team tracker
using the Support Request template. This process allows us to track time involved
and ensure that the right parties are involved at the correct time.
Requests should be opened two or more business days before action is needed to ensure the team has time to prepare.
How did Distribution get its name? We iterated, as always. "Distribution" was chosen as better than "Install" when renaming the original "Build" team, live on an AMA with our CEO Sid. Since then we have iterated further in order to grow the team, and now have subgroups for "Build" and "Deploy".
(Sisense↗) We also track our backlog of issues, including past due security and infradev issues, and total open System Usability Scale (SUS) impacting issues and bugs.
(Sisense↗) MR Type labels help us report what we're working on to industry analysts in a way that's consistent across the engineering department. The dashboard below shows the trend of MR Types over time and a list of merged MRs.
(Sisense↗) Flaky test are problematic for many reasons.