The Gitaly team is responsible for building and maintaining systems to ensure that the Git data storage tier of GitLab instances, and GitLab.com in particular, is reliable, secure and fast. For more information about Gitaly, see our Direction page.
Provide a durable, performant, and reliable Git storage layer for GitLab.
The following people are permanent members of the Gitaly Team:
|Andras Horvath||Manager, Engineering, Gitaly|
|Christian Couder||Senior Backend Engineer, Gitaly|
|James Fargher||Senior Backend Engineer, Gitaly|
|John Cai||Senior Backend Engineer, Gitaly|
|Justin Tobler||Backend Engineer, Gitaly|
|Karthik Nayak||Senior Backend Engineer, Gitaly|
|Patrick Steinhardt||Staff Backend Engineer, Gitaly|
|Pavlo Strokov||Senior Backend Engineer, Gitaly|
|Quang-Minh Nguyen||Senior Backend Engineer, Gitaly|
|Sami Hiltunen||Senior Backend Engineer, Gitaly|
|Toon Claes||Senior Backend Engineer, Gitaly|
|Will Chandler||Senior Backend Engineer, Gitaly|
The following members of other functional teams are our stable counterparts:
|Mark Wood||Senior Product Manager, Systems:Gitaly|
|Furhan Shabir||Senior Site Reliability Engineer, Systems:Gitaly|
|Igor Drozdov||Senior Backend Engineer, Create:Source Code, Systems:Gitaly API|
|John McDonnell||Senior Software Engineer in Test, Systems:Gitaly|
|Calliope Gardner||Site Reliability Engineer, Systems:Gitaly|
|Steve Azzopardi||Senior Site Reliability Engineer, Systems:Gitaly|
|Vasilii Iakliushin||Senior Backend Engineer, Create:Source Code, Systems:Gitaly API|
While GitLab is the primary consumer of the Gitaly project, Gitaly is a standalone project which can be used external to GitLab. As such, we strive to achieve a functional boundary around Gitaly. The goal of this is to ensure that the Gitaly project creates an interface to manage Git data, but does not make business decisions around how to manage the data.
For example, Gitaly can provide a robust and efficient set of APIs to move Git repositories between storage solutions, but it would be up to the calling application to decide when such moves should occur.
Processes fully independent of business inputs (such as repository maintenance) should be fully contained within Gitaly as they provide substantial value to anyone using the Gitaly project.
Gitaly team members do not carry pagers, but we live around the world and there's a good chance that someone is available during their working hours. There is no coverage for weekends; instead, we strive to empower incident responders to mitigate any circumstance.
These issues relate to ongoing production outages or similar. They interrupt our process used to schedule work and get attention as soon as possible. Please only interrupt us sparingly, in these cases:
Getting attention on an urgent, interrupting issue
@gl-gitaly(the whole team) on the issue.
We use the standard engineering workflow to schedule work. To get Gitaly team
work on something, it's best to create an issue on the Gitaly issue tracker
and add the
~"workflow::problem validation" labels,
along with any other appropriate labels. Then, feel free to tag the relevant
Product Manager and/or Engineering Manager as listed above.
For information requests and other quick one-offs, feel free to use #g_gitaly on Slack to get attention on the issue.
These are typically Corrective Actions or other followup items that have strict SLO tracking. They will be scheduled through either of the above paths, by EM and/or PM polling these dashboards:
A weekly call is held between the product manager and engineering manager, which is listed in the "Gitaly Team" calendar. Everyone is welcome to join and these calls are used to discuss any roadblocks, concerns, status updates, deliverables, or other thoughts that impact the group.
To have a constant communication flow about planned changes, updates and maybe breaking changes we have the #g_gitaly Slack channel. In the channel we will provide updates for all teams using the service but also ask for assistance to provide feedback and insights about planned changes or improvements.
To support this pro-active communication additionally there is also an individual counterpart on the consumer side to help with research in the codebases and coordination with all the teams consuming Gitaly. The DRI on Consumer side is Igor Drozdov.
The Gitaly consumers are:
At the beginning of each release, the Gitaly EM will create a retrospective issue to collect discussion items during the release. The first weekly Gitaly meeting after the 18th that issue will be used to discuss what was brought up.
(Sisense↗) We also track our backlog of issues, including past due security and infradev issues, and total open 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.
To complete team-specific onboarding, file an issue here.
Maintainer rights are revoked, and to remove the developer from the list of
authorized approvers, remove them from the
gl-gitaly GitLab.com group.