Development

This page is dedicated to database application engineering and provides an entry-point for resources on this topic.

Also see Database Team in Enablement.

GitLab development

Please refer to the development documentation for database guidelines.

Database Roles at GitLab

We have two primary job roles that are focused on the database aspect:

1. Backend Engineer, Database - in Development
2. Database Reliability Engineer - in Infrastructure

The Backend Engineer, Database role is a software engineering role concentrated on application-side improvements and foundational database work in the GitLab codebase.

Vision

Enable engineers across the world by having top notch planning and issue tools for managing their work, awesome tools to organize their code and evolve their codebase through the best code review and online editing experience. Support organizations to have an easy entrance level to use GitLab by having great import capabilities, a great documentation experience and administration tools.

We thrive for ownership of the things that we built by having a clear view on its performance and stability in production. We constantly challenge ourselves to build a better, faster and more robust application.

Resources

Secure coding best practices

It is important that all developers are aware of secure coding best practices and refresh this knowledge periodically. This is tracked via Secure Coding Training Guidelines.

Ruby on Rails Performance Training

The materials from an earlier Ruby on Rails performance workshop can be found on internally shared Google drive.

Video Sessions

Database

Here is the information of a PostgreSQL query optimization bot at GitLab - Joe: Blueprint and Design.

Executive Summary

Key Performance Indicators

Past Due InfraDev Issues

Measures the number of past due infradev issues by severity.

Overview

There are specific scenarios we are identifying that will require additional approval before moving forward. At GitLab we value freedom and responsibility over rigidity, however in the examples requiring approval section below we outline which decisions will need to go through the approval process before proceeding.

Approval Process

Each section requiring approvals will have a considerations section. If you answered yes to all of the questions in the considerations section, then you will need to get approval for your proposal before proceeding with implementation. Steps for the approval process:

Engineering Principles

At GitLab, Company Culture is very important to us. The main ingredient of the company culture are GitLab Values.

GitLab Values have guided us throughout the evolution of the company. Those values have been crucial in maintaining a positive and productive culture, helping us make decisions to make the company and the product better.

Our Engineering Principles are built on top of GitLab Values, and provide additional explanation of these in the context of the software engineering practice.

Incubation Engineering Department

The Incubation Engineering Department focuses on projects that are pre-Product/Market fit. The projects they work on align with the term “new markets” from one of our product investment types. They are ideas that may contribute to our revenue in 3-5 years time. Their focus should be to move fast, ship, get feedback, and iterate. But first they’ve got to get from 0 to 1 and get something shipped.

Secure Coding Training Guidelines

It is essential that all developers are aware of secure coding best practices and refresh this knowledge periodically.

Why

• It reduces the chances of security issues being introduced into GitLab.
• Some developers want to learn secure coding as a part of their ongoing learning.
• It may help to make customers and auditors more comfortable with the security of our product.

Background

• Secure coding training was done in late July of 2019.
• Secure coding is an onboarding task for new developers.

What challenges does this address?

• We do not track who has taken the training to gauge our security risk.
• We do not encourage developers to do the training if they have not previously taken the course.
• We do not have a plan to motivate GitLab Team Members to refresh their knowledge of secure coding periodically.

Considerations

• We want to encourage GitLab Team Members to take this training and periodically refresh their knowledge of it because they believe it is relevant to them and the company. We do not want to force it on them.
• We want to track how many GitLab Team Members have taken the training / refreshed their knowledge on it to encourage full participation; however, we do not want to make it feel punitive to them if they have not yet done so.
• We want to avoid burdening engineers with the tracking of these activities.

The Plan

February 2020

• Create an issue and list each manager and the number of direct reports that are engineers in a table: 6406
• Ask managers to update the issue with how many engineers on each team have indicated that have taken the training.
• Ask managers to encourage those who have not taken the training to do so.

We chose to have engineering managers track this for their teams vs. using the acknowledgment process as it is believed it will cause it to be better received.

This page is for any development manager notes we want to share more broadly. A directory was created in case we need to archive or break out content.

FY21 Compensation Review

The following is a brief for engineering managers to help in their conversations with team members about compensation. This document is to give additional context on the FY'21 compensation plan and how GitLab views compensation. It should be viewed as complementary to the handbook information.