Skip to content

Thoughts on GitLab Product organisation

Background

We currently have a product split along the following lines:

  • Platform
  • CI/CD
  • Discussion
  • Build
  • Prometheus
  • GitLab.com Plans, Licensing & Purchasing

Some areas are growing too big for management by a single person, Platform has now been split between @mydigitalself and @jramsay. Unfortunately the split is somewhat arbitrary, although mildly grouped.

Additionally, we have some mildly orphaned product structures:

  • Geo
  • Gitaly

We keep talking about creating "Feature Teams", but features seem to be short-lived or perhaps too granular a structure by which to organise. That's not to say we can't deal with them in such a way, more on this to follow.

There is talk of aligning product around our marketing materials or phases of DevOps such as Plan, Create, Verify, Package, Release, Configure & Monitor. Whilst understandable, this leaves a lot on the table and additionally has a lot of potential functional overlap. This is not to say this is a bad idea, and certainly some of these areas will appear in my proposal below.

Proposal

Firstly, this is a proposal. I'm pretty sure I've got a lot wrong. I've been involved in exercises like this in the past at Skype where we've had incredibly smart people argue for days and weeks on end on the product taxonomy; no matter what, you'll never settle on a completely perfect structure. You just need to pick one that works well for you.

Many people are probably aware of Spotify Squads and how the engineering structure forms around core functional areas where that team's raison d'etre is to systematically improve their area and they have a strong sense of autonomy and ownership.

Without in-depth knowledge of how some teams are structured and some of their functional concerns, below is a proposal for splitting up product teams that includes Product, Frontend, Backend & UX people. Please note that full-stack teams including shipping, deploying & monitoring their code have not been considered owing to the monolith structure of our application, but that's not to say it couldn't be achieved.

Team Overview

  • Server Management
  • Planning & Project Management
  • Code & Review
  • Build & Deploy
  • Monitor
  • Integrations
  • Navigation, Search & Notifications aka Personal Productivity
  • Content

Some of these teams may be larger than others, some may even require two product people, but I think there may be a stronger sense functional area.

Team Detail

Server Management

The server management team's mission is to make GitLab simple to install, setup and run.

This means the following functional areas are covered:

  • Build + Omnibus (and install)
  • Gitaly
  • User Management (Permissions, LDAP, etc...)
  • Groups & Subgroups
  • Admin Area
  • Auditing
  • Geo
  • Backup & Restore

This team may be fairly large, and could possibly be split into two:

  • Core
  • Build + Omnibus (and install)
  • Gitaly
  • Geo
  • Back & Restore
  • User & Group Administration
  • User Managment
  • Groups & Subgroups
  • Admin Area
  • Auditing

Planning & Project Management

This team's mission is making managing the development lifecycle as simple and powerful as possible.

Functional Areas:

  • Issues
  • Issue boards
  • Portfolio Management
  • Service Desk

Specifically included from this team is MRs, this forms part of code & review. Even though the code and some of the UI may have the same structure or shape, reviewing code is a separate concern.

Code & Review

This team's mission is to help teams produce high-quality software together. It includes:

  • Projects & Repos (starting projects)
  • Repo Editor (this may be a team of it's own?!)
  • Templates
  • Merge Requests
  • Auto Code Quality
  • Review Apps
  • Snippets

There is of course perhaps a lot of overlap here:

  • Starting Projects & Templates could be considered part of Server Managaement & Administration as there are controls in place
  • Merge Requests, as mentioned, are currently coupled with Issues
  • Code Quality & Review apps are currently part of CI

This is a good example of where teams depend on one another and should be exposing capability through API. For instance, the Merge Request should not only be a vehicle of review, but should also show code quality status, build status, license checks, privacy checks (pushing tokens) and review apps, which are probably all booted up and executed through the Build & Deploy team.

Build & Deploy

I debated long and hard where to put this one, but I think it deserves it's own team. This team serves two purposes. The first is to make the process of building software easy for our customers and their developers. The second is enabling the Code + Review team via APIs to perform Auto Code Quality & Review Apps.

It includes:

  • CI / Build
  • Runners
  • Containerisation
  • Deploy Boards

Monitor

Monitor is fairly clear, this team exists to help people understand how their code performs and includes:

  • Prometheus
  • Monitoring Dashboards
  • Monitoring integration (e.g. output into Issues & MRS)

Integrations

I know this has been an area of debate, and we currently even classify certain integrations under their area of expertese (Jira, Slack, etc.. = Discussion, Jenkins = CI).

I personally think this should be owned separately. This team's core competency should be in setting up other applications and understanding how best to integrate them with GitLab in a simple way as well as making sure our API, oAuth, App Directory is simple to work with.

Functional Areas:

Navigation, Search & Notifications aka Personal Productivity

This may seem like a weird one, but this enables cross-GitLab productivity. The fact that the best way to find something in GitLab is to search Gmail is crazy.

Functional areas:

  • Overall Navigation
  • Initial user onboarding
  • Search + ElasticSearch
  • Notifications (email + TODO)

Content

This team doesn't exist yet, I'm not sure if we need it, but we may need to find another home for these items, which sorely lack attention at the moment and certainly have a place in the software developer lifecycle as documentation plays a big part and certainly Confluence is heavily used in the enterprise.

Functional Areas:

  • Wiki
  • GitLab Pages
  • Internal docs? i.e. docs.gitlab.com
Edited by Mike Bartlett