A world class development team of software engineers and managers who make our customers happy when using our product(s). Our products should contain broad rich features, high availaiblity, high quality, fast performance, trustworthy security, and reliable operation.
The development department strives to deliver MRs fast. MR delivery is a reflection of:
The department also focuses on career development and process to make this a preferred destination for high performing software engineers.
We use data to make decisions. If data doesn't exist we use anecdotal information. If anecdotal information isn't available we use first principles.
The development team is responsible for developing products in the following categories:
The following people are permanent members of the Development Department:
|Christopher "Leif" Lefelhocz||VP of Development|
|Stan Hu||Engineering Fellow|
|Tim Zallmann||Director of Engineering, Dev|
|Chun Du||Director of Engineering, Enablement|
|Sam Goldstein||Director of Engineering, Ops|
|Lily Mai||Operations Analyst, Development|
|Bartek Marnane||Director of Engineering, Fulfillment|
|Todd Stadelhofer||Director of Engineering, Secure|
|Wayne Haber||Director of Engineering, Threat Management and Growth|
The following members of other functional teams are our stable counterparts:
|Giuliana Lucchesi||People Business Partner, Development and Product (interim)|
This is the breakdown of our department by section and by stage.
This is the stack-up of our engineers, by level.
Welcome to GitLab! We are excited for you to join us. Here are some curated resources to get you started:
Issues that impact code in another team's product stage should be approached collaboratively with the relevant Product and Engineering managers prior to work commencing, and reviewed by the engineers responsible for that stage.
We do this to ensure that the team responsible for that area of the code base is aware of the impact of any changes being made and can influence architecture, maintainability, and approach in a way that meets their stage's roadmap.
At times when cross-functional, or cross-departmental architectural collaboration is needed, the GitLab Architecute Evolution Workflow should be followed.
Development's headcount planning follows the Engineering headcount planning and long term profitability targets. Development headcount is a percentage of overall engineering headcount. For FY20, the headcount size is 271 or ~58% of overall engineering headcount.
The following is a non exhaustive list of daily duties for engineering directors, while some items are only applicable at certain time, though.
In general, OKRs flow top-down and align to the company and upper level organization goals.
For managers and directors, please refer to a good walk-through example of OKR format for developing team OKRs. Consider stubbing out OKRs early in the last month of the current quarter, and get the OKRs in shape (e.g. fleshing out details and making them SMART) no later than the end of the current quarter.
It is recommended to assess progress weekly.
Below are tips for developing individual's OKRs:
The GitLab application is built on top of many shared services and components, such as PostgreSQL database, Redis, Sidekiq, Prometheus and so on. These services are tightly woven into each feature's rails code base. Very often, there is need to identify the DRI when demand arises, be it feature request, incident escalation, technical debt, or bug fixes. Below is a guide to help people quickly locate the best parties who may assist on the subject matter.
There are a few available models to choose from so that the flexibility is maximized to streamline what works best for a specific shared service and component.
The shared services and components below are extracted from the GitLab product documentation.
|Service or Component||Sub-Component||Ownership Model||DRI (Centralized Only)||Ownership Group (Centralized Only)||Additional Notes|
|Email - Inbound|
|Email - Outbound|
|GitLab K8S Agent|
The materials from an earlier Ruby on Rails performance workshop can be found on internally shared Google drive.
|Session - Day 1||Intro and overview||Monday Wednesday|
|Session - Day 2||Tools||Monday Wednesday|
|Session - Day 3||SQL and N+1 Troubleshooting||Monday Wednesday|
|Session - Day 4||Queueing Theory||Monday Wednesday|
Frontend Masters allows you to advance your skills with in-depth, modern frontend engineering courses.
GitLab has an account with Frontend Masters and team members can gain access to it by creating an Access Request and select the best option for your situation (single user, bulk user, etc.) and, once approved by your manager, assign to the Access Request Provisioner listed in the Tech Stack for this system. Once your access has been provisioned, you will receive an email to activate your account.
You can also join the #frontendmasters Slack channel for course recommendations and discussion.
We use GraphQL alongside our REST API at GitLab and are increasingly adding new features to the GraphQL API over time.
The GraphQL API can be added to by anyone, including community members. We have a group of self-selected team members who are willing to help with any GraphQL questions you may have. You can get in touch with them by mentioning
@gitlab-org/graphql-experts in any GitLab issue or merge request.
You can read more information about GraphQL at GitLab here:
We also run GraphQL office hours, which is a place where GitLab team members can ask questions and chat amongst peers about GraphQL at GitLab.
These meetings are currently run on a weekly cadence, alternating between timezones.
|Time in UTC||Organisers|
In late June 2019, we moved from a monthly release cadence to a more continuous delivery model. This has led to us changing from issues being concentrated during the deployment to a more constant flow. With the adoption of continuous delivery, there is an organizational mismatch in cadence between changes that are regularly introduced in the environment and the monthly development cadence.
To reduce this, infrastructure and quality will engage development via
Availability & Performance
represents critical issues to be addressed in development from infrastructure
and quality. Issues on this board are tagged with
labels. A director from development will be assigned to refine the board, work
with product/infrastructure/quality to set priority/severity of issues, make sure they
are assigned and worked, and escalate where necessary for resolution.
Refinement will happen on a weekly basis and involve a member of infrastructure, quality, product management, and development.
Rapid Action, as the name implies, is the process we use when a critical situation arises needing immediate attention from various stakeholders. When the situation is identified as a potential Rapid Action the following guidance is recommended.
It is recommended that daily progress is updated in the agenda. Once the exit criteria has been met, remove the
rapid action label, close the rapid action issue and prepend the agenda document with "Closed" or "Deprecated" to indicate its status.
Available email alias (a.k.a. Google group):
Managers, Directors, VP's teams: each alias includes everyone in the respective organization.
email@example.com, examples below -
Teams roll up by the org chart hierarchy -
Note: books in this section can be expensed.