Offer enterprise-grade operational experience of GitLab products from streamlined deployment and maintenance, disaster recovery, secure search and discoverability, to high availability, scalability, and performance.
Core Platform focuses on improving our capabilities and metrics in the following areas:
The following people are permanent members of teams that belong to the Core Platform Sub-department:
|Alex Ives||Backend Engineering Manager, Database|
|Diogo Frazão||Backend Engineer, Database|
|Jon Jenkins||Senior Backend Engineer, Database|
|Krasimir Angelov||Senior Backend Engineer, Database|
|Leonardo da Rosa||Backend Engineer, Database|
|Matt Kasa||Senior Backend Engineer, Database|
|Prabakaran Murugesan||Senior Backend Engineer, Database|
|Simon Tomlinson||Senior Backend Engineer, Database|
|Rick Mar||Engineering Manager, Database Reliability|
|Alexander Sosna||Senior Database Reliability Engineer|
|Biren Shah||Senior Database Reliability Engineer|
|Rafael Henchen||Senior Database Reliability Engineer|
|Sahil Mehta||Senior SRE in Database Reliability|
|Peter Lu||Backend Engineering Manager, Distribution:Deploy|
|Clemens Beck||Distribution Engineer, Distribution:Deploy|
|Hossein Pursultani||Senior Distribution Engineer, Distribution:Deploy|
|Jason Plum||Staff Distribution Engineer, Distribution:Deploy|
|João Alexandre Prado Tavares Cunha||Senior Distribution Engineer, Distribution:Deploy|
|Jon Doveston||Distribution Engineer, Distribution:Deploy|
|Mitch Nielsen||Senior Distribution Engineer, Distribution:Deploy|
|Juan Silva||Fullstack Engineering Manager, Geo|
|Aakriti Gupta||Senior Backend Engineer, Geo|
|Douglas Barbosa Alexandre||Staff Backend Engineer, Geo|
|Gabriel Mazetto||Senior Backend Engineer, Geo|
|Ian Baum||Senior Backend Engineer, Geo|
|Javiera Tapia||Backend Engineer, Geo|
|Kyle Yetter||Senior Backend Engineer|
|Michael Kozono||Staff Backend Engineer, Geo|
|Zack Cuddy||Senior Frontend Engineer, Geo|
|Andras Horvath||Manager, Engineering, Gitaly|
|Ahmad Sherif||Senior Site Reliability Engineer|
|Emily Chui||Senior Backend Engineer, Gitaly|
|James Liu||Senior Backend Engineer, Gitaly|
|Justin Tobler||Backend Engineer, Gitaly|
|Patrick Steinhardt||Staff Backend Engineer, Gitaly|
|Quang-Minh Nguyen||Staff Backend Engineer, Gitaly and Tenant Scale|
|Sami Hiltunen||Staff Backend Engineer, Gitaly|
|Will Chandler||Senior Backend Engineer, Gitaly|
|Changzheng Liu||Backend Engineering Manager, Global Search|
|Dmitry Gruzd||Staff Backend Engineer, Global Search|
|John Mason||Senior Backend Engineer, Global Search|
|Madelein van Niekerk||Backend Engineer, Global Search|
|Ravi Kumar||Backend Engineer, Global Search|
|Siddharth Dungarwal||Backend Engineer, Global Search|
|Terri Chu||Staff Backend Engineer, Global Search|
|Tomáš Bulva||Senior Frontend Engineer, Global Search|
|Paul John Phillips||Backend Engineering Manager, Cloud Connector|
|Aleksei Lipniagov||Senior Backend Engineer, Cloud Connector|
|Matthias Käppler||Staff Backend Engineer, Cloud Connector|
|Nikola Milojevic||Senior Backend Engineer, Cloud Connector|
|Roy Zwambag||Backend Engineer, Cloud Connector|
|Arturo Herrero||Engineering Manager, Tenant Scale|
|Abdul Wadood||Senior Backend Engineer, Tenant Scale|
|Alex Pooley||Staff Backend Engineer, Tenant Scale|
|Manoj Memana Jayakumar||Senior Backend Engineer, Tenant Scale|
|Omar Qunsul||Backend Engineer, Tenant Scale|
|Peter Hegman||Senior Frontend Engineer, Tenant Scale|
|Rutger Wessels||Senior Backend Engineer, Tenant Scale|
|Steve Xuereb||Staff Site Reliability Engineer, Tenant Scale|
|Thong Kuah||Principal Engineer, Tenant Scale|
The following members of other functional teams are our stable counterparts:
|Amy Qualls||Senior Technical Writer, Create (Source Code, Code Review), Core Platform (Database)|
|Achilleas Pipinellis||Senior Technical Writer, Core Platform|
|Grant Young||Staff Software Engineer in Test, Core Platform:Distribution|
|Kassandra Svoboda||Manager, Quality Engineering, Core Platform & SaaS Platform|
|Nick Westbury||Senior Software Engineer in Test, Core Platform:Geo|
|Vishal Patel||Software Engineer in Test, Core Platform:Systems|
|Joshua Lambert||Director of Product Management, Core Platform|
(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.
In order to embody GitLab CREDIT values, we take team status update to async. Instead of reporting on status in meetings, Directors, Senior Engineering Managers, Engineering Managers provide weekly async updates. The content of these updates may vary week over week but generally cover:
We use issues to communicate status asynchronously. The reporting issues reside in Core Platform Status Update project. There are two types of report issues - issues for each group, stage, and Director; summary issues for each week and month for quick access. The creation of these issues is automated by scripts and a cron job in the same project. The summary issues are also updated regularly by the same cron job to pull the latest together.
Engineering managers are encouraged to make as many updates as needed throughout the week.
~Core Platform::Weekly-Updatelabel are summarized in weekly and monthly issues, for example W23 Core Platform Sub-Dept Status Summary (2022-06-12 - 2022-06-18), M6 Enablement Sub-Dept Status Summary (Jun 2022).
The nature of the work primarily done by most Core Platform groups calls for backend heavy roadmaps and backlogs. This means that frontend (FE) development work can be "stop-and-go" and typically does not warrant the need for a full-time FE developer assigned to those groups. However, when work does come up it can be overwhelming for the group in question, or they may not have the necessary FE development skills to complete the task.
To address this need, the enablement sub-department has established a cross-group frontend development process. The objective is to have extra frontend engineering capacity readily available to help all enablement groups with frontend development work overload while avoiding going through formal borrow requests and their process overhead. This also has the added benefit of having some level of technical oversight that supports a consistent frontend architecture across groups.
The process itself consists of managing a unified enablement frontend roadmap and backlog. The DRI of this process is the Engineering Manager of Geo (@juan-silva). While the frontend engineers' primary focus is still their own groups' roadmap, they can be made available for this backlog based on demand, availability, and overall priority assessment upon agreements between respective groups' PMs and EMs coordinated by the DRI.
The roadmap is depicted in the table below. This roadmap is reviewed regularly on a monthly cadence during one of the Core Platform staff meetings. Additionally, ad-hoc planning sessions can be scheduled on request by other Core Platform EMs, when more prioritization is needed to balance the needs of different group stakeholders.
|Global Search||Gitlab Chat||16.0||MVC Epic|
|Tenant Scale||Migrate user tabs to Vue||16.1||Epic|
Effort is based on T-shirt sizes as follows: Small = Up to 1 week, Medium = 2-6 weeks, Large = 2-3 months, XL = more than 3 months
As the frontend roadmap items above are broken down into specific Epics and Issues, they are added to each individual group's backlog using that group’s own labels. Additionally, those issues must be labelled with
New issues must initially be labeled
workflow::planning breakdown where they can be assessed from a technical perspective and estimated accordingly. From there, issues are expected to follow the workflow steps outlined in the Core Platform Frontend Backlog board. Geo's FE Engineer is the DRI for updating the board regularly as development progresses.
Documenting development decisions is another way to increase efficiency. These decisions can be either in an issue explicitly stating that we will not work on this issue, the product category page for your group or a more formal decision log in your group's section of the handbook. Whatever your chosen desitination, each group should try to maintain a single source of truth for the decisions. A recent example (without mentioning specific product name) had a development team researching an open source product to accelerate development time only to find out later that this research had been previously completed and the product was eliminated from consideration. If this decision had been discoverable via documentation or issue it would have saved precious development time.
We have started creating decision logs to benefit our internal development team as well as our greater GitLab community. It is up to each group to determine the best location for decision logs to be discoverable. For example, the Database team has a decision log for Sharding GitLab with CitusDB in the Core Platform/Database section of the handbook and a decision log for the Sharding Working Group in the working group section of the handbook.
For issues, a clear decision is when an issue is successfully closed. However, if an issue is closed because we "won't do it" it may not be immediately clear. We are adopting the
~won't do label for those issues. Often the pattern is to just stash these issues in the
~backlog. This can be misleading to those watching the issue and frustrating to the original author, especially if they are a community contributor. When we apply a
won't do label to an issue, we are making a clear decision. If there is no pushback on the
won't do label then we made the right decision. If there is pushback and we need to reprioritize the issue, then that is a good outcome as well.
We hold our bar high when it comes to hiring. Our goal is to hire the best candidates who will make GitLab successful meanwhile ensuring that the candidates are also set up for success at GitLab. With that in mind, our interview panels consist of a minimum of 4 interviewers (a.k.a. 4 scorecards), and there is no upper bound if needed. However, typically it won't go beyond 6 interviewers in total. Our interview panels are designed so that multiple data points are available from different interviewers for a specific factor, such as technical competency. This lets us confidently make decisions by cross referencing interview feedback in order to avoid the risk of single data source.
To bring the best possible candidate experience and stay competitive, we schedule all interviews at once and try to fit all in a small time window. This means the interviews are not serial and the scheduling of an interview doesn't depend on the outcome of another one. On the other hand, we will give candidates advanced notice that the interview process can halt at any time and we will notify them if the case. This is to respect the candidates' time when we believe the candidate is a better fit for other opportunities.
optional, the Hiring Manager and their counterpart Product Manager can decide together whether Product Manager is invited to the interview panel
Peer Team Member Intervieware separate, the hiring manager can feel free to determine how many engineers are invited to each interview as long as a minimum of 2 engineers will provide independent feedback of technical assessments.
Strong Yesscorecards, excluding the recruiting call
must-havesassessed and positive (
nice-to-havesassessed and positive
nice-to-havesthe same way as required in #2 and #3. The ratings should reflect the hiring manager's evaluation of the candidate based on all feedback. They are not an average of scores given by the interview panel.
The Core Platform teams leverage the following software or SaaS services to deliver our products. For general information of procurement, checkout the procurement team page. For procurement questions, bring to #procurement. To make new Purchase Order (PO), create a new procurement issue.
|Software||Vendor Link||Term||Renewal Date||Team Impacted||Comments|
|packagecloud.io||https://packagecloud.io/||Annual||March 30th||Distribution||Existing vendor, last renewal issue, last renewal PO|
|dependencies.io||https://www.dropseed.io/||Annual||November 1st||Distribution||Existing vendor, last renewal issue|
|postgres.ai||https://postgres.ai/||Annual||May 28th||Database||Existing vendor, last renewal issue|