Engineering

FY24 Direction

GitLab has a Three-Year Strategy, and we’re excited to see every member of the Engineering division contribute to achieving it. Whether you’re creating something new or improving something that already exists, we want you to feel empowered to bring your best ideas for influencing the product direction through improved scalability, usability, resilience, and system architectures. And when you feel like you need to expand your knowledge in a particular area, know that you’re supported in having the resources to learn and improve your skills.

Our focus on FY24 is to make sure that GitLab is enterprise grade in all its abilities and to support the AI efforts required to successfully launch Code Suggestions and GitLab Duo to General Availability.

Making sure that GitLab is enterprise grade involves several teams collaborating on improving our disaster recovery and support offerings through ongoing work with GitLab Dedicated, and Cells infrastructure. Our goal here is improved availability and service recovery.

Engineering Culture

Engineering culture at GitLab encompasses the processes, workflows, principles and priorities that all stem from our GitLab Values. All these things continuously strengthen our engineering craftsmanship and allow engineers to achieve engineering excellence, while growing and having a significant, positive impact on the product, people and the company as a whole. Our engineering culture is primarily being carried, and evolves, through knowledge sharing and collaboration. Everyone can be part of this process because at GitLab everyone can contribute.

Engineering Excellence

Engineering excellence can be defined as an intrinsic motivation to improve engineering efficiency, software quality, and deliver better results while building software products. Engineering excellence is being fueled by a strong engineering culture combined with a mission: to build better software that allows everyone to contribute.

Engineering Initiatives

Engineering is the primary advocate for the performance, availability, and security of the GitLab project. Product Management prioritizes 80% of engineering time, so everyone in the engineering function should participate in the Product Management prioritization process to ensure that our project stays ahead in these areas. Engineering prioritizes 20% of time on initiatives that improve the underlying platform and foundational technologies we use.

  • Review fixes from our support team. These merge requests are tagged with the Support Team Contributions label. You can filter on open MRs.
  • Working on high priority issues as a result of issue triaging. This is our commitment to the community and we need to include some capacity to review MRs or work on defects raised by the community.
  • Improvements to the performance, stability and scalability of a feature. Again, the Product team should be involved in the definition of these issues but Engineering may lead here by clearly defining the recommended improvements.
  • Improvements and upgrades to our toolchain in order to boost efficiency.

Community Contributions

We have a 3-year goal of reaching 1,000 monthly contributors as a way to mature new stages, add customer-desired features that aren’t on our roadmap, and even translate our product into multiple languages.

Diversity

Diverse teams perform better. They provide a sense of belonging that leads to higher levels of trust, better decision making, and a larger talent pool. They also focus more on facts, process facts more carefully, and are more innovative. By hiring globally and increasing the numbers of women and ethnic minorities in the Engineering division, we’re helping everyone bring their best selves to work.

Growing our team

Hiring is still a top priority in FY24, and we’re excited to continue hiring people who are passionate about our product and have the skills to make it the best DevSecOps tool in the market. Our current focus areas include reducing the amount of time between offer and start dates and hiring a diverse team (see above). We’re also implementing industry-standard approaches like structured, behavioral, and situational interviewing to help ensure a consistent interview process that helps to identify the best candidate for every role. We’re excited to have a recruiting org to partner with as we balance the time that managers spend recruiting against the time they spend investing in their current team members.

Expand customer focus through depth, and stability

As expected, a large part of our focus in FY24 is on improving our product.

For Enterprise customers, we’re refining our product to meet the levels of security and reliability that customers rightfully demand from SaaS platforms (SaaS Reliability). We’re also providing more robust utilization metrics to help them discover features relevant to their own DevOps transformations (Usage Reporting) and offering the ability to purchase and manage licenses without spending time contacting Sales or Support (E-Commerce and Cloud Licensing). Lastly, in response to Enterprise customer requests, we’re adding features to support Suggested Reviewers, better portfolio management through Work Items, and Audit Events that provide additional visibility into user passive actions.

For Free Users, we’re becoming more efficient with our open core offering, so that we can continue to support and give back to students, startups, educational institutions, open source projects, GitLab contributors, and nonprofits

For Federal Agencies, we’re obtaining FedRAMP certification to strengthen confidence in the security standards required on our SaaS offering. This is a mandated prerequisite for United States federal agencies to use our product.

For Hosted Customers, we’re supporting feature parity between Self-Managed and GitLab Hosted environments through the Workspace initiative. We’re also launching GitLab Dedicated for customers who want the flexibility of cloud with the security and performance of a single-tenant environment.

For customers using CI/CD, we’re expanding the available types of Runners to include macOS, Linux/Docker, and Windows, and we’re autoscaling build agents.

Engineering Departments

There are four departments within the Engineering Division:

Workflows

GitLab in Production

People Management

Cross-Functional Prioritization

See the Cross-Functional Prioritization page for more information.

SaaS Availability Weekly Standup

To maintain high availability, Engineering runs a weekly SaaS Availability standup to:

  • Review high severity (S1/S2) public facing incidents
  • Review important SaaS metrics
  • Track progress of Corrective Actions
  • Track progress of Feature Change Locks

Infrastructure Items

Each week the Infrastructure team reports on incidents and key metrics. Updating these items at the top of the Engineering Allocation Meeting Agenda is the responsibility of the Engineering Manager for the General Squad in Reliability.

  1. Incident Review
    • Include any S1 incidents that have occurred since the previous meeting.
    • Include any incidents that required a status page update.
  2. SaaS Metrics Review
    1. Include screenshots of the following graphs in the agenda.

Development Items

For the core and expansion development departments, updates on current status of:

  1. Error budgets
  2. Reliability issues (infradev)
  3. Security issues

Groups under Feature Change Locks should update progress synchronously or asynchronously in the weekly agenda. The intention of this meeting is to communicate progress and to evaluate and prioritise escalations from infrastructure.

Feature Change Locks progress reports should appear in the following format in the weekly agenda:

FCL xxxx - [team name]

  • FCL planning issue: <issue link>
  • Incident Issue: <issue link>
  • Incident Review Issue: <issue link>
  • Incident Timeline: <link to Timeline tab of the Incident issue>
    • e.g. time to detection, time to initiate/complete rollback (as applicable), time to mitigation
  • Cause of Incident
  • Mitigation
  • Status of Planned/completed work associated with FCL

Feature Change Locks

A Feature Change Lock (FCL) is a process to improve the reliability and availability of GitLab.com. We will enact an FCL anytime there is an S1 or public-facing (status page) S2 incident on GitLab.com (including the License App, CustomersDot, and Versions) determined to be caused by an engineering department change. The team involved should be determined by the author, their line manager, and that manager’s other direct reports.

If the incident meets the above criteria, then the manager of the team is responsible for:

  • Form the group of engineers working under the FCL. By default, it will be the whole team, but it could be a reduced group if there is not enough work for everyone.
  • Plan and execute the FCL.
  • Inform their manager (e.g. Senior Manager / Director) that the team will focus efforts towards an FCL.
  • Provides updates at the SaaS Availability Weekly Standup.

If the team believes there does not need to be an FCL, approval must be obtained from either the VP of Infrastructure or VP of Development.

Direct reports involved in an active borrow should be included if they were involved in the authorship or review of the change.

The purpose is to foster a sense of ownership and accountability amongst our teams, but this should not challenge our no-blame culture.

Timeline

Rough guidance on timeline is provided here to set expectations and urgency for an FCL. We want to balance moving urgently with doing thoughtful important work to improve reliability. Note that as times shift we can adjust accordingly. The DRI of an FCL should pull in the timeline where possible.

The following bulleted list provides a suggested timeline starting from incident to completion of the FCL. “Business day x” in this case refers to the x business day after the incident.

  • Day 0: Incident:
  • Business day 1: relevant Engineering Director collaborates with VP of Development and/or VP of Infrastructure or their designee to establish if FCL is required.
  • Business day 2: confirmation that an FCL is required for this incident and start planning.
  • Business days 3-4: planning time
  • Business days 5-9 (1 week): complete planned work
  • Business days 10-11: closing ceremony, retrospective and report back to standup

Activities

During the FCL, the team(s) exclusive focus is around reliability work, and any feature type of work in-flight has to be paused or re-assigned. Maintainer duties can still be done during this period and should keep other teams moving forward. Explicitly higher priority work such as security and data loss prevention should continue as well. The team(s) must:

  • Create a public slack channel called #fcl-incident-[number], with members
    • The Team’s Manager
    • The Author and their teammates
    • The Product Manager, the stage’s Product leader, and the section’s Product leader
    • All reviewer(s)
    • All maintainers(s)
    • Infrastructure Stable counterpart
    • The chain-of-command from the manager to the VP (Sr Manager, Sr/Director, VP, etc)
  • Create an FCL issue in the FCL Project with the information below in the description:
    • Name the issue: [Group Name] FCL for Incident ####
    • Links to the incident, original change, and slack channel
    • FCL Timeline
    • List of work items
  • Complete the written Incident Review documentation within the Incident Issue as the first priority after the incident is resolved. The Incident Review must include completing all fields in the Incident Review section of the incident issue (see incident issue template). The incident issue should serve as the single source of truth for this information, unless a linked confidential issue is required. Completing it should create a common understanding of the problem space and set a shared direction for the work that needs to be completed.
  • See that not only all procedures were followed but also how improvements to procedures could have prevented it
  • A work plan referencing all the Issues, Epics, and/or involved MRs must be created and used to identify the scope of work for the FCL. The work plan itself should be an Issue or Epic.
  • Daily - add an update comment in your FCL issue or epic using the template:
    • Exec-level summary
      • Target End Date
      • Highlights/lowlights
  • Add an agenda item in the SaaS Availability weekly standup and summarize status each week that the FCL remains open.
  • Hold a synchronous closing ceremony upon completing the FCL to review the retrospectives and celebrate the learnings.
    • All FCL stakeholders and participants shall attend or participate async. Managers of the groups participating in the FCL, including Sr. EMs and Directors should be invited.
    • Agenda includes reviewing FCL retrospective notes and sharing learnings about improving code change quality and reducing risk of availability.
    • Outcome includes handbook and GitLab Docs updates where applicable.
Scope of work during FCL

After the Incident Review is completed, the team(s) focus is on preventing similar problems from recurring and improving detection. This should include, but is not limited to:

  • Address immediate corrective actions to prevent incident reoccurrence in the short term
  • Introduce changes to reduce incident detection time (improve collected metrics, service level monitoring, which users are impacted)
  • Introduce changes to reduce mitigation time (improve rollout process through feature flags, and clean rollbacks)
  • Ensure that the incident is reproducible in environments outside of production (Detect issues in staging, increase end-to-end integration test coverage)
  • Improve development test coverage to detect problems (Harden unit testing, make it simpler to detect problems during reviews)
  • Create issues with general process improvements or asks for other teams

Examples of this work include, but are not limited to:

  • Fixing items from the Incident Review which are identified as causal or contributing to the incident.
  • Improving observability
  • Improving unit test coverage
  • Adding integration tests
  • Improving service level monitoring
  • Improving symmetry of pre-production environments
  • Improving the GitLab Performance Tool
  • Adding mock data to tests or environments
  • Making process improvements
  • Populating their backlog with further reliability work
  • Security work
  • Improve communication and workflows with other teams or counterparts

Any work for the specific team kicked off during this period must be completed, even if it takes longer than the duration of the FCL. Any work directly related to the incident should be kicked off and completed even if the FCL is over. Work paused due to the FCL should be the priority to resume after the FCL is over. Items created for other teams or on a global level don’t affect the end of the FCL.

A stable counterpart from Infrastructure will be available to review and consult on the work plan for Development Department FCLs. Infrastructure FCLs will be evaluated by an Infrastructure Director.

Engineering Performance Indicator process

The Quality Department is the DRI for Engineering Performance Indicators. Work regarding KPI / RPI is tracked on the engineering metrics board and task process.

Manual verification

We manually verify that our code works as expected. Automated test coverage is essential, but manual verification provides a higher level of confidence that features behave as intended and bugs are fixed.

We manually verify issues when they are in the workflow::verification state. Generally, after you have manually verified something, you can close the associated issue. See the Product Development Flow to learn more about this issue state.

We manually verify in the staging environment whenever possible. In certain cases we may need to manually verify in the production environment.

If you need to test features that are built for GitLab Ultimate then you can get added to the issue-reproduce group on production and staging environments by asking in the #development Slack channel. These groups are are on an Ultimate plan.

Critical Customer Escalations

We follow the below process when existing critical customer escalations requires immediate scheduling of bug fixes or development effort.

Requirements for critical escalation

  • Customer is in critical escalation state
  • The issues escalated have critical business impact to the customer, determined by Customer Success and Support Engineering leadership
    • Failure to expedite scheduling may have cascading business impact to GitLab
  • Approval from a VP from Customer Success AND a Director of Support Engineering are required to expedite scheduling

Process

  • The issue priority is set to ~"priority::1" regardless of severity
  • The label ~"critical-customer-escalation" is applied to the issue
  • The issue is scheduled within 1 business day
    • For issues of type features, approval from the Product DRI is needed.
  • The DRI or their delegate provides daily process updates in the escalated customer slack channel

DRI

  • If issue is type bug DRI is the Director of Development
  • If issue is type feature DRI is the Director of Product
  • If issue requires Infrastructure work the DRI is the Engineering Manager in Infrastructure

The DRI can use the customer critical merge requests process to expedite code review & merge.

Pairing Engineers on priority::1/severity::1 Issues

In most cases, a single engineer and maintainer review are adequate to handle a priority::1/severity::1 issue. However, some issues are highly difficult or complicated. Engineers should treat these issues with a high sense of urgency. For a complicated priority::1/severity::1 issue, multiple engineers should be assigned based on the level of complexity. The issue description should include the team member and their responsibilities.

Team Member Responsibility
Team Member 1 Reproduce the Problem
Team Member 2 Audit Code Base for other places where this may occur

If we have cases where three or five or X people are needed, Engineering Managers should feel the freedom to execute on a plan quickly.

Following this procedure will:

  • Decrease the time it takes to resolve priority::1/severity::1 issues
  • Allow for a smooth handover of the issue in case of OOO or End of the Work Day
  • Provide support for Engineers if they are stuck on a problem
  • Provide another set of eyes on topics with high urgency or securing security-related fixes

Canary Testing

Information on canary testing has been moved to dedicated page covering the canary stage and how to use it

Engineering private handbook

There are some engineering handbook topics that we cannot be publicly transparent about. These topics can be viewed by GitLab team members in the engineering section of the private handbook.

If you experience a page not found (404) error when attempting to access the internal handbook, you may need to register to use it via first browsing to the internal handbook authorization page.


Architecture
Complexity at Scale As GitLab grows, through the introduction of new features and improvements on existing ones, so does its complexity. This effect is compounded by the care and feeding of a single codebase that supports the wide variety of environments in which it runs, from small self-managed instances to large installations such as GitLab.com. The company itself adds to this complexity from an organizational perspective: hundreds employees worldwide contribute in one way or another to both the product and the company, using GitLab.
compensation-roadmaps
Core Development Department
Vision Scale and develop our diverse, global team to drive results that support our product and customer growth, while maintaining our values and unique way of working. Mission GitLab’s unique way of working asynchronously, handbook first, using the product we develop, and with clear focus on our values enables very high productivity. In delivering on growth, we maintain our values and ways of working while developing team members and increasing the diversity of our team.
Cross Functional Prioritization
Cross-Functional Prioritization Purpose Achieve and maintain an optimal balance of new features, security fixes, availability work, performance improvements, bug fixes, etc. via a framework that helps drive conversations and alignment. Balance across these categories will allow GitLab to operate in a way that will allow us to meet revenue goals and maintain the stability of our platform. Give voice to everyone in the quad (PM, Development, Quality, and UX) Provide transparency into prioritization and work status to internal and external stakeholders so they can advocate for their work items Implementation Philosophy The quad members (UX/Design, Quality, Product Management, Development) utilizing this process should focus on:
CTO Staff
Engineering All-Hands The Engineering All-Hands meeting happens monthly on alternating time slots in place of a CTO Office Hours. The purpose is to share company updates, stay connected, and receive feedback. The entire Engineering group is invited, though anyone at GitLab is welcome to attend and contribute to the All-Hands agenda (internal). As with all general meetings at GitLab, attendance is optional though encouraged, and will be recorded. Engineering Offsite The quarterly Engineering offsite provides a forum for longer-form discussion among the CTO’s direct reports.
Deployments and Releases
Overview and terminology This page describes the deployment and release approach used to deliver changes to users. The overall process consists of two significant parts: 1 Monthly self-managed release: GitLab version (XX.YY.0) published every month. From this monthly release, patch, non-critical, and critical security releases are created as needed 1 GitLab.com deployment: A Continous Delivery process to deploy branches created from master branch, on regular intervals. For more details on the individual processes and how to use them please see the Deployments page for GitLab.
Development
Engineering Career Development
The Three Components of Career Development There are three important components of developing one’s career: Structure Team members who are (or want to be) on track for promotion should be engaged in a career coaching conversation with their manager. Some basic information about this process can be found in the People Ops handbook. Specific coaching plan templates are listed here to help start the conversation: Senior Engineer (Others to come) We want to build these documents around the career matrix for Engineering.
Engineering Communication
Communication GitLab Engineering values clear, concise, transparent, asynchronous, and frequent communication. Here are our most important modes of communication: GitLab Issue Tracker: Please use confidential issues for topics that should only be visible to team members at GitLab. Start with a Merge Request: The most effective way to make a change to the company is to make a proposal in the form of a merge request to the handbook and assign it to the DRI.
Engineering Dashboarding and Metrics
Engineering Analytics Dashboard Inventory Several dashboards have been published to the Engineering project in the Tableau environment. Below is a brief overview of some of the dashboards created and where you can find them. Centralized Engineering Metrics Please refer to our Centralized Engineering Metrics page here. Tableau Dashboards You can find published dashboards in Ad-hoc/Development/General. These dashboards are safe for general use by the Tableau User population here at GitLab.
Engineering Demo Process
Occasionally, it is useful to set up a demo on a regular cadence to ensure cross-functional iterative alignment. This is helpful for high-impact deliverables that require integration across multiple functional teams. This is in-line with the seventh principle of the Agile Manifesto: “Working Software is the best measure of progress”. Demo script For multi-person groups or critical projects, we use a heavier weight grading process: The demo owner identifies the outcome of the demo based on the business criteria.
Engineering Error Budgets
The error budget provides a clear, objective metric that determines how unreliable the service is allowed to be within a single quarter.
Engineering Fellow Shadow
GitLab engineers: work with an Engineering Fellow for a week
Engineering Function Performance Indicators
Executive Summary KPI Health Status Engineering Handbook MR Rate Okay Above target Engineering Team Member Retention Okay above target, constant trend Engineering Vacancy Time to Fill Attention Trending upNeed to coach hiring managers to lean in while recruiting rebuilds Key Performance Indicators Engineering Handbook MR Rate The handbook is essential to working remote successfully, to keeping up our transparency, and to recruiting successfully. Our processes are constantly evolving and we need a way to make sure the handbook is being updated at a regular cadence.
Engineering Hiring
Hiring Practices Please reference our internal hiring repository for internal best practices and guidelines. R&D New Headcount GHPID Request, Backfill & Transfer Process New Headcount and Backfill Processes Budgeted new headcount review occurs on a regular basis across Engineering Leadership, Talent Acquisition, Finance Business Partners (FPB), and People Business Partners (PBP). The process to open a new headcount is Talent Acquisition and Finance-driven, with a focus on ensuring communication, consistency and collaboration between the Engineering and People teams.
Engineering IC Leadership
Engineering IC Leadership at GitLab: going beyond Senior level At GitLab, it is expected that everyone is a manager of one. For Individual Contributors (IC) a new type of challenge begins with the Staff Engineer role. Engineering IC Leadership is an alternative career path to Engineering Management. Just like moving into management, also moving from Senior to Staff changes the day-to-day work and expectations placed on ICs. Engineering IC Leaders exert technical leverage in their scope of influence.
Engineering Internships
Learn about GitLab's engineering internship program.
Engineering Management
How Engineering Management Works at GitLab At GitLab, we promote two paths for leadership in Engineering. While there is a healthy degree of overlap between these two ideas, it is helpful and efficient for us to specialize training and responsibility for each of: Technical leadership, as represented by Staff and higher-level engineers. Professional leadership, as represented by Engineering management. While technical leadership tends to come naturally to software engineers, professional leadership can be more difficult to master.
Engineering Mentorship
Mentorship, Coaching and Engineering Programs Line Managers and Senior Individual Contributors The PlatoHQ Program has a total of 10 Engineering Managers/Senior IC’s participating. The program exists of both self-learning via an online portal and 1-1 sessions with a mentor. Senior Leaders in Engineering The 7CTOs Program is run with 4 Senior leaders in Engineering. The program exists of peer mentoring sessions (forums) and effective network building. CTO customer executive sponsor shadow The CTO is an executive sponsor for selected customers.
Engineering OKRs
Here is the standard, company-wide process for OKRs. Engineering has some small deviations from (and extensions to) this process. Historical OKRs All of our past OKRs are available to the public HERE. Active OKRs FY24-Q2 The source of truth for GitLab OKRs and KRs is GitLab. CTO objectives and KRs are aligned to company OKRs on this page. 1. CTO: Continue to win against GitHub with AI in all we do CTO KR: Enhanced Support offering ready for launch in Q3 CTO KR: Experimental launch of Remote Development feature used by 10 team members to develop GitLab features CTO KR: Create a foundation in support of rapid experimentation CTO KR: 48 experimental, 16 beta, and 8 GA AI Assisted features delivered 2.
Engineering Projects
Name Location AI Gateway gitlab-org/modelops/applied-ml/code-suggestions/ai-assist Analytics Configurator gitlab-org/analytics-section/analytics-configurator Analytics Stack gitlab-org/analytics-section/product-analytics/analytics-stack Auto Build Docker Image cluster-integration/auto-build-image Auto Deploy Docker Image cluster-integration/auto-deploy-image Autoscaler Custom Executor driver for GitLab Runner gitlab-org/ci-cd/custom-executor-drivers/autoscaler GitLab Helm Repository charts/charts.gitlab.io Cloud Deploy gitlab-org/cloud-deploy Managed Cluster Applications Docker Image cluster-integration/cluster-applications Cloud Native GitLab containers gitlab-org/build/CNG Container Registry gitlab-org/container-registry Cookbook Omnibus GitLab gitlab-org/cookbook-omnibus-gitlab CustomersDot (Subscription Portal) gitlab-org/customers-gitlab-com Data Infrastructure gitlab-data/data-image GitLab Data Chatops gitlab-data/chatops Declarative Policy gitlab-org/ruby/gems/declarative-policy Pajamas Design System gitlab-org/gitlab-services/design.
Engineering Secondments
Learn about GitLab's secondment program for external engineers.
Engineering Team Readmes
Engineering Workflow
This document explains the workflow for anyone working with issues in GitLab Inc.
Expansion Development Department
Vision Scale and develop our diverse, global team to drive results that support our product and customer growth, while maintaining our values and unique way of working. Mission GitLab’s unique way of working asynchronously, handbook first, using the product we develop, and with clear focus on our values enables very high productivity. In delivering on growth, we maintain our values and ways of working while developing team members and increasing the diversity of our team.
Fast Boot
A Fast Boot is an event that gathers the members of a team or group in one physical location to work together and bond in order to accelerate the formation of the team or group so that they reach maximum productivity as early as possible. History of the Fast Boot The first Fast Boot took place in December 2018. The 13 members of Monitor Group gathered for 3 days to work and bond in Berlin.
Frontend Group
Teams Configure Create Manage Monitor Plan Secure Verify and Release Frontend domain experts You can find engineers with expertise in various frontend domains on the engineering projects page under the following sections: GitLab maintainers with domain expertise GitLab reviewers with domain expertise You can reach out to these experts to get help on: discussing and defining the architecture of complex frontend features. frontend technical topics like Vue, GraphQL, CSS, testing, tooling, etc.
GitLab Plato HQ Mentoring Program
Program Overview GitLab has partnered with Plato HQ for an external Mentoring Program. In this program GitLab team members select Mentors external to GitLab. Some of the other Mentoring programs we have here at GitLab are internal to GitLab. Minorities in Tech and Women in Sales are both made up of GitLab Mentors and GitLab Mentees. The external mentoring is what makes this approach to GitLab unique. For more information on mentoring best practice, visit Mentoring.
GitLab Repositories
GitLab consists of many subprojects. A curated list of GitLab projects can be found at the GitLab Engineering projects page. Creating a new project When creating a new project, please follow these steps: Read and familiarize yourself with our stance on Dogfooding. Be aware that as part of a product development organization that builds a tool for people like us, that our default is to add features and tooling to the GitLab project.
Guide to Engineering Analytics Data
Introduction Engineering Analytics is responsible for building and evolving analytics capabilities and creating insights for Engineering to understand how well we are building our product. In this case, “wellness” is measured in terms of efficiency, as well as cost. Our main role as engineering analysts is to support department heads or DRI in creating or updating their metrics so that they can use them in the key meetings. Data Sources Dive into our analytics by exploring the specific data sources that underpin our metrics.
Guidelines for automation and access tokens
Guidelines for automation with project/group tokens or service accounts
Incident
Definition of an Incident The definition of “incident” can vary widely among companies and industries. Here at GitLab, incidents are anomalous conditions that result in — or may lead to — service degradation, outages, or other disruptions. These events require human intervention to avert disruptions, communicate status, restore normal service, and identify future improvements. Incidents are always given immediate attention. Incident Management Incident Management is the process of responding to, mitigating, and documenting an incident.
Infrastructure
The Infrastructure Department is responsible for the availability, reliability, performance, and scalability of GitLab.com and other supporting services
Infrastructure and Quality department
Vision Our vision is to be a world-class Infrastructure & Tools department that enables GitLab to meet & exceed our customers’ needs. We: Build critical infrastructure, metrics & tools that enable GitLab Engineering & Product teams to do their best work efficiently and ship high-quality & reliable products to our customers. Are customer focused. We have an ambitious drive to attain high availability & reliability for SaaS platforms and self-managed customers.
Monitoring of GitLab.com
GitLab.com Service Availability Service Availability is the percentage of time during which the platform is in an available state. Other states are degraded and outage. Each of the user facing services have two Service Level Indicators (SLI): the Apdex score, and the Error rate. The Apdex score is generally a measure of the service performance (latency). The Error rate measures the percentage of requests that fail due to an error (usually, a 5XX status code).
Open Source at GitLab
We believe in Open Source As a company, GitLab is dedicated to open source. Not only do we believe in it, but we use it, and we give back to it. Not just through GitLab, but through contributions to other open source projects. The purpose of this page is to document how a GitLab employee can: Create an open source project on behalf of GitLab Contribute to a third-party open source project on behalf of GitLab Use a third-party open source code in a GitLab’s project Growth Strategy As an open source project, we want to stay healthy and be open for growth, but also ready to accommodate a 10x factor of our community.
Performance
Performance Facets We categorize performance into 3 facets Backend Frontend Infrastructure Backend performance Backend performance is scoped to response time of API, Controllers and command line interfaces (e.g. git). DRI: Christopher Lefelhocz, VP of Development. Performance Indicators: Memory Utilization (backlog) Frontend performance Frontend performance is scoped to response time of the visible pages and UI components of GitLab. DRI: Christopher Lefelhocz, VP of Development. Performance Indicators: Largest Contentful Paint (LCP) Infrastructure performance Infrastructure performance is scoped to the performance of GitLab SaaS Infrastructure.
Quality Department
The Quality Department in Engineering Division
R&D Tax Credits
GitLab submits applications for R&D Tax Credits in a number of jurisdictions that implement reimbursement schemes for research and development. A subject-matter expert (SME) from engineering is appointed to each application to assist with data collection. A third-party tax agent prepares and submits the report. SMEs are usually Engineering Managers or Directors and located in, or with reasonable knowledge of, the jurisdiction under application. Role of the SME The role of the SME is twofold:
Recognition in Engineering
Engineering Quarterly Achievers Quarterly, CTO Leadership will recognize Engineering team members who have excelled in a given quarter. Recognition includes: an invitation to the Engineering Quarterly Achievers Chat participation in the Engineering Quarterly Achiever’s Recognition Dinner - an expensed meal for yourself, friends and family to celebrate your work, the meal must occur before the last day of the quarter following the announcement. Winners each quarter have until the last day of the quarter to submit for reimbursement.
Releases
Overview and terminology This page describes the processes used to release packages to self-managed users. Monthly self-managed release GitLab version (XX.YY.0) is published every month. From this monthly release, patch, non-critical, and critical security releases are created as needed. Our maintenance policy describes in detail the cadence of our major, minor and patch releases for self-managed users. The major release yearly cadence was defined after an all stakeholder discussion. Self-managed overview The self-managed release is a semver versioned package containing changes from many successful deployments on GitLab.
Root Cause Analysis
At GitLab transparency is one of our core values, as it helps create an open and honest working environment and service, which it turn accelerates growth and innovation. We treat a root cause analysis (RCA) as an opportunity to be transparent amongst our organization and community by investigating what went well and what didn’t after working on a project, incident, or issue. This page defines an RCA, the benefits of completing them, and how to complete a successful RCA here at GitLab.
Starting new teams
Starting new teams Our product offering is growing rapidly. Occasionally we start new teams. Backend teams should map to our product categories. Backend teams also map 1:1 to product managers. A dedicated team needs certain skills and a minimum size to be successful. But that doesn’t block us from taking on new work. This is how we iterate our team size and structure as a feature set grows: Existing Team: The existing PM schedules issues for most appropriate existing engineering team If there is a second PM for this new feature, they work through the first PM to preserve the 1:1 interface Shared Manager Team: Dedicated engineer(s) are identified on existing teams and given a specialty The manager must do double-duty Their title can reflect both specialties of their engineers e.
Volunteer Coaches for URGs
Pilot Program Overview This program allows team members at GitLab to volunteer and donate their time and technical skills (such as programming or Linux administration) to provide knowledge, support, and coaching to members of underrepresented groups (URGs) in the technology industry. The hope is we can help people who have been denied opportunity for whatever reason, and desire to get their first job in the technology industry. This program is in pilot as of November 1, 2020.
Last modified February 21, 2024: Remove sisense refs from eng misc pages (41d004c5)