The Database team focuses on improving performance, reliability, and availability of GitLab and GitLab.com. This is done through a variety of different ways such as:
For further details, see the current vacancy for a Database Engineer.
During your first month at GitLab as a database engineer or specialist we expect you to get familiar with GitLab, set up a working environment, and work on a few simple issues. Available issues can be found in the issue boards mentioned below. If there are no issues available or you are not certain what to work on it's best to discuss this with your team members.
After the first month (depending on how fast you get started this might take less than a month) we expect you to start focusing on work for a specific functional group. Currently the following groups are available:
Once you have chosen a functional group you will be primarily working on the issues related to that group, though you're of course more than welcome to also work on other issues. You will also be expected to help the members of those teams by helping them write better database queries, review merge requests, etc. Of course you don't have to do all of this at once, instead the team will help you ease into this process step by step.
You are free to switch groups at any time, though we prefer for this to be announced in the weekly database meeting so that everybody is aware of this. When doing so you should also inform the team leads of both the old and new team so they are aware of the change.
Note that when focusing on the work of a specific team you do not report to that team's lead or manager, instead you still report to the database team.
To make it easier to find your way around you can find a list of useful or important links below.
As a database specialist the following tools can be very helpful:
pbin GitLab and a bar with performance metrics will show up at the top of the page. This tool is especially useful for viewing the queries executed and their timings.
EXPLAIN ANALYZEfor executed queries. Enable by starting Rails with
env ENABLE_SHERLOCK=1 bundle exec rails s.
The following (private) Grafana dashboard are important / useful for database specialists:
Basically everything under https://docs.gitlab.com/ee/development/README.html#databases, but the following guides in particular are important:
For various other development related guides refer to https://docs.gitlab.com/ee/development/README.html.
We recommend you join at least the following Slack channels:
Don't try to keep up with everything as some of these channels can see a lot of activity, instead just idle there in case somebody needs you. The most important channel is
We also recommend turning off
@channel mentions for
#development to reduce the amount of unwanted notifications.
Make sure you are a member of the group https://gitlab.com/gitlab-org/database-specialists. This makes it easier to assign merge request approvers or mention all database specialists at once.
There are four main repositories database engineers work in:
We also primarily use the following labels:
To make it easier to work we have the following issue boards:
Always make sure an issue exists for the work you are about to perform. As a rule of thumb: work does not exist unless there is an issue for it. Issues are not only used to describe the work to do, but also to track progress. Make sure you update your issues on a regular basis with your findings, statistics, progress, etc. It's better to share too much information on the work being done than to share too little.
We recommend you only assign issues to yourself if you are actively working on them. If you are simply interested in an issue it's best left unassigned until you are working on it. This way you don't end up with an issue list that is thousands of issues long with no progress being made.
Don't sit around doing nothing if you can't find anything to work on! Instead just ask what should be done in the
#database channel if no AP1/2/3 issues are available.
For planning we use so called "Weekly Goals". Weekly goals are written in an issue that's created for the next work week / sprint. These work weeks range from Wednesday to the end of the next Tuesday. These issues are assigned to all database specialists. Some examples of these issues:
The work to be done is planned together with other database specialists. When planning try to plan enough for 4 or so days, but make sure you don't plan too much. It's better to plan less and achieve everything than to plan a lot and achieve very little.
The format of the issue bodies is fairly straightforward: for every database specialist there is a checklist referring to other issues (perhaps with some brief info) to perform, which are checked off as work is completed. Checklists can be created using the following Markdown:
* [ ] This is an item on my checklist * [x] This item is marked as done
The results of the weekly goals are discussed in the weekly infrastructure call, which takes place 30 minutes before the team call.
An overview of existing issues can be found at https://gitlab.com/gitlab-com/database/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name=Weekly+Goals.
To make it easier to create these issues you can use the issue template "Database Goals".
To prevent yourself from getting buried in unread notifications it's best to adjust the default notification settings of your GitLab account. We recommend the following:
@gl-infra(which can happen quite a lot).
Using this setup you will not get any Email notifications. TODOs are still created but only if somebody mentions your username or a group you are a member of.
We recommend turning off Slack notification popups as these can be quite invasive, especially when multiple notifications are displayed at once. Turning off the sound notifications can also greatly help as you won't be distracted every time somebody sends you a message or mentions your username.