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 Specialist.
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 3 main repositories database specialists work in:
We also primarily use the following labels:
To make it easier to work we have the following issue boards:
For the Infrastructure repository we don't have AP issues, instead you can just use the following link to list all "database" issues: https://gitlab.com/gitlab-com/infrastructure/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name=database.
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/infrastructure/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name=database&label_name=goal.
To make it easier to create these issues you can use the Infrastructure 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.