Upgrade improvements

The working group aims to enhance customer’s experience of the entire lifecycle of upgrading a self-managed GitLab instance.

Attributes

Property Value
Date Created 2024-10-01
Target End Date TBD
Slack

#wg_upgrade_improvements (only accessible from within the company)
Google Doc

Working Group Agenda (only accessible from within the company)

Project Plan (only accessible from within the company)
Epic

GitLab self-managed upgrade improvements
Label

WorkingGroup::UpgradeImprovements
Status Active

Goals

The Upgrade Improvements Working Group is a cross-functional group focused on Upgrade Improvements project, one of the top CTO priorities. The project aims to enhance customer’s experience of the entire lifecycle of upgrading a self-managed GitLab instance.

The specific high level goals

  1. Expand upgrade cadence options for GitLab users (ie. LTS)
  2. Organizational changes in code development
  3. Decrease operational requirements of upgrading GitLab
  4. Appoint end-to-end owner of GitLab release

Other goals

  1. Remove required upgrade stops from GitLab upgrade cadence
  2. Breaking changes are limited to major releases

Overview

Upgrading GitLab can be challenging, varying in difficulty from upgrade to upgrade and deployment. The working group reviewed FY25 emergency upgrade tickets so far, gitlab.com deployment blocker dashboard, and customer conversations, group Distribution is also reviewing and validating current upgrading process.

We have found that the current upgrade process itself works in general, there are user experience improvements that can be made to lower the barrier of upgrades, but the upgrade process itself works as intended today. The main challenges are product bugs, configuration issues, migration bug and migration taking too long, these problems are largely existing in the pre- and post- upgrade phases.

Hence, the working group decided to address these concerns in multiple phases.

Phase Focus areas ETA
Phase 1
  • Database improvements
  • Code quality
  • Introduce Support Spikes process
  • Perform UX research
 FY25 Q4
Phase 2
  • Provide option for long term support (LTS) versions
  • TBD
 TBD
Phase X
  • TBD
 TBD

Refer to Upgrade Improvements project plan (Internal only) and the project Epic for more details.

Exit Criteria

The north star of this working group is increasing the number of self-managed GitLab instances running on maintained versions. However, given that metrics can be influenced by various factors, and some of them are beyond our control, specific exit criteria for each phase are outlined below:

Phase Exit Criteria
Phase 1
  • Decrease number of self-managed emergency upgrade support tickets relating to database migration
  • TBD
Phase 2
  • TBD
Phase X
  • TBD

Roles and Responsibilities

Working Group Role Person Title
Executive Stakeholder Sabrina Farmer Chief technology officer (CTO)
Facilitator Peter Lu Engineering Manager, Distribution::Deploy
Functional Lead - Product & Distribution Dilan Orrino Senior Product Manager Distribution
Functional Lead - Test Platform Kassandra Svoboda Engineering Manager, Test Platform
Functional Lead - Support Brie Carranza Staff Support Engineer
Functional Lead - Expansion Software Development Thomas Woodham Senior Engineering Manager, Secure
Functional Lead - Core Development Luke Duncalfe Staff Backend Engineer, Manage:Import and Integrate
Functional Lead - Core Development Erran Carey Staff Fullstack Engineer, Create::Editor Extensions
Member Gerardo Lopez-Fernandez Engineering Fellow, Infrastructure
Member Vincy Wilson Director, Test Platform
Member Lyle Kozloff Director, Support Engineering
Member Stan Hu Engineering Fellow
Last modified November 7, 2024: Removing Nick, Mike, myself from the working group (23aef117)
View page source - Edit this page - please contribute. Creative Commons License