The First Month

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

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:

Production: everything related to the infrastructure that powers GitLab.com. This team is best suitable for those with a strong infrastructure / operations background.

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.

Common Links

To make it easier to find your way around you can find a list of useful or important links below.

Monitoring & Performance Related Tools

Performance Bar: type pb in 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.

Sherlock: a tool similar to the performance bar but meant for development environments. Sherlock is able to show backtraces and the output of EXPLAIN ANALYZE for executed queries. Enable by starting Rails with env ENABLE_SHERLOCK=1 bundle exec rails s.

"AP1", "AP2" and "AP3": for estimating/specifying the performance and availability priority (from high to low). See "Availability and Performance Priority Labels" for more information. In short: AP1 is the most important, AP3 the least.

"performance": for performance related issues and merge requests.

"OKR-DB": issues to be completed in the current OKR.

Issue Boards

To make it easier to work we have the following issue boards:

OKR Issue Board: this board lists all the issues we should complete in the current OKR.

Creating Issues

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.

Assigning Issues

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.

Ask!

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.

Weekly Goals

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.

Make sure "Receive notifications about your own activity" is unchecked.

Disable notifications for the "gl-infra" group if you are a member, unless you are interested in getting notifications whenever somebody mentions @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.

Slack Notifications

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.