Development Analytics Group

Common Links

Category	Handle
GitLab Group Handle	@gl-dx/development-analytics
Slack Channel	#g_development_analytics
Slack Handle	@dx-development-analytics
Team Boards	Team Issues Board, Team Epics Board, Support Requests
Issue Tracker	tracker
Team Repositories	development-analytics

Mission

Our mission is to enhance developer efficiency by delivering actionable insights, optimizing pipeline performance, and building scalable productivity tools that measurably improve the software development lifecycle.

Vision

We envision a future where GitLab’s development workflows are seamless, insightful, and empowered by data. The Development Analytics team will:

• Establish GitLab as the industry benchmark for measurable developer productivity
• Improve cycle time to industry-leading standards through tooling and practices
• Create intuitive, powerful analytics dashboards that drive informed development decisions
• Deploy AI-powered systems that optimize pipeline performance and resource utilization

Team members

Name	Role
Paul John Phillips	Engineering Manager, Development Analytics / Feature Readiness
Andrejs Cunskis	Senior Software Engineer in Test, Development Analytics
David Dieulivol	Senior Backend Engineer, Development Analytics
Ievgen Chernikov	Senior Software Engineer in Test, Development Analytics
Pranshu Sharma	Intermediate Backend Engineer, Development Analytics
Lohit Peesapati	Intermediate Backend Engineer, Development Analytics

Core Responsibilities

flowchart LR
    DA[Development Analytics Team]

    DA --> MRCT[MR Cycle Time Improvement]
    DA --> Tools[Tooling Maintenance]

    MRCT --> Analytics[Analytics & Observability]
    MRCT --> ExecTime[Pipeline Execution Time Optimization]
    MRCT --> ReviewEng[Review Engagement Enhancement]
    MRCT --> PipeStab[Pipeline Stability Assurance]

    Tools --> Triage[Triage Ops]
    Tools --> Roulette[GitLab Roulette]
    Tools --> Danger[Dangerfiles]
    Tools --> EPInfra[Engineering Productivity Infrastructure]
    Tools --> CNG[CLI for Cloud Native GitLab deployment]

    click Triage "https://gitlab.com/gitlab-org/quality/triage-ops"
    click Roulette "https://gitlab.com/gitlab-org/gitlab-roulette"
    click Danger "https://gitlab.com/gitlab-org/ruby/gems/gitlab-dangerfiles"
    click EPInfra "https://gitlab.com/gitlab-org/quality/engineering-productivity-infrastructure"
    click Analytics "https://gitlab.com/groups/gitlab-org/-/epics/16185"
    click ExecTime "https://gitlab.com/groups/gitlab-org/-/epics/15989"
    click ReviewEng "https://gitlab.com/groups/gitlab-org/-/epics/16028"
    click PipeStab "https://gitlab.com/groups/gitlab-org/-/epics/16186"
    click MRCT "https://gitlab.com/groups/gitlab-org/-/epics/16026"
    click CNG "https://gitlab.com/gitlab-org/gitlab/-/tree/master/qa/gems/gitlab-cng"

Roadmap

As part of our commitment to aligning with GitLab’s company goals, our team conducts a thorough review of company-level Roadmap and Objectives and Key Results (OKRs) at the beginning of each quarter. This process ensures that our efforts are strategically focused on delivering high-impact results that contribute to the broader organizational objectives. View the Development Analytics Roadmap for FY26 for detailed insights and upcoming priorities

Dashboards

Pipeline Duration Analytics

• Pipeline Duration Analytics
• Job Execution Analytics
• Pipeline Tier Analysis
• Long-Running Test Analysis

Pipeline Stability Analytics

• Main Branch Incident Analytics
• E2E Test Analytics

Note: Access to these dashboards requires appropriate permissions. Contact team leads for access requests.

How we work

Philosophy

• We prioritize asynchronous communication and a handbook-first approach, in line with GitLab’s all-remote, timezone-distributed structure.
• We emphasize the Maker’s Schedule, focusing on productive, uninterrupted work.
• Most critical recurring meetings are scheduled on Tuesdays and Thursdays.
• We dedicate 3–4 hours weekly for focused learning and innovation. This protected time enables the team to explore emerging technologies, conduct proof-of-concepts, and stay current with industry trends. Meeting requests during these blocks require advance notice.
• All meeting agendas can be found in the Team Shared Drive as well as in the meeting invite.

Meetings/Events

Event	Cadence	Agenda
End-of-Week progress update	Once a week (Wednesday)	Summarize status, progress, ETA, and areas needing support in the weekly update in issues and Epics. We leverage epic-issue-summaries bot for automated status checks
Team meeting	Twice a month on Tuesday 4:00 pm UTC	Agenda
Monthly Social Time	Monthly on last Thursday 4:00 pm UTC	No agenda, fun gathering. Choose one of the slots based on your timezone alignment. Read Virtual team building
Quarterly Business Report	Quarterly	Contribute to team’s success, learnings, innovations and improvement opportunities for each business quarter
1:1 with Engineering Manager	Weekly	Discuss development goals (see the 1:1 guidelines)
Team member’s coffee chats	Once/twice a month	Optional meetings for team members to regularly connect

Yearly Roadmap Planning

• Each financial year, we create a roadmap to ensure visibility and alignment.
• We conduct an intensive month-long exercise (usually in Q4) to gather input from stakeholders.
• DRIs take the lead drafting the roadmap using the roadmap prep-work template).
• Once the roadmap is approved, during our bi‑weekly team meetings, we review progress, address blockers, and gather feedback on the planned roadmap work.

Iterations

Once the yearly roadmap is defined, we structure our work using GitLab Iterations within a twice-a-month iteration model. This approach ensures consistent progress tracking, clear priorities, and iterative improvements. Here are our current iteration board and previous iterations for reference. As a team, we make sure:

1. Each issue is assigned to a Development Analytics Iteration.
2. Issues that are not worked on within the iteration automatically roll over to the next iteration.
3. In every twice-a-month team meeting, we review the iteration boards and track velocity using burndown charts.

Internal Rotation & Support Requests

Internal Rotation

We use an internal rotation for support requests and other team maintenance tasks. This frees up time for other Engineers in the team to work on planned work.

Support Requests

• If one finds a bug, needs assistance, or identifies an improvement opportunity then raise support requests using the ~"group::Development Analytics" and ~"development-analytics::support-request" labels. If the issue is urgent, escalate to the designated Slack channel - #g_development_analytics.
• If a request first comes through Slack, either the requester or a group::Development Analytics member should open an issue with the correct labels to ensure proper tracking and triage.
• The team reviews the support request board and prioritizes accordingly. Generally, the team reserves ~20% of weekly time for support tasks, though this may vary based on current priorities.

Tools/Repository Maintenance

• Team does not automatically watch every new issue created in each group-owned repository—use the group labels or escalate in Slack to ensure visibility.
• We highly promote self-served Merge Requests. If one already identified a fix or improvement, we request opening an MR for faster turnaround. The ~group::development analytics maintainers will review and merge as appropriate.
• Feature work and bug fixes follow the team’s current priorities.
• Find the version management rituals for ~group::development analytics owned repositories:

Repository	Release Process
gitlab-roulette	Version updates are not scheduled on a set cadence. A release can be cut whenever a version-update MR is submitted.
gitlab-dangerfiles	Same as above—no regular cadence; release triggered by a version-update MR.
triage-ops	A new release is initiated after merging a new commit into master.
engineering-productivity-infrastructure	Dependency update MRs are generated by Renovate bot.

Automated Label Migration

For details on label migration, see the Handbook entry for creating label migration triage policy with GitLab Duo Workflow.

Our Data Needs

Our team requires flexible and responsive data infrastructure to support rapid experimentation and real-time monitoring. This section outlines our current platform capabilities and decision-making framework for choosing the appropriate data platform.

Current State Analysis

Requirement	Our Expectation	Why We Need This	Snowflake	Internal Events (Snowflake)*	BigQuery + Grafana
Data Latency	< 30 minutes	Real-time incident detection, master-broken monitoring	❌ 12+ hours for GitLab.com data**	❌ 12+ hours for GitLab.com data**	✅ < 5 minutes
Self-service Access	No approval workflows	Rapid experimentation without delays	❌ Approval needed	✅ MR review only	✅ Available
Email/Slack Alerts	Native integration	Automated incident response and monitoring	❌ Not available (requires Tableau)	❌ Not available	✅ Native support
Flexible Data Sources	Self-service addition	Quick iteration from idea to experiment	❌ Data team required	✅ MR review only	✅ Self-service
Programmatic API	Full API access	Automated data processing and integration	⚠️ Some friction, high security requirements	⚠️ Some friction, high security requirements	✅ Full Ruby client

*Internal Events is a mechanism to push data to Snowflake through MR reviews rather than data team projects, but the resulting data still suffers from GitLab.com data availability delays and other limitations.

GitLab.com Data Limitations: We can ingest data from a GCS bucket quite quickly, including real-time streaming if needed. For GitLab.com, we’re constrained by the schedule of when data becomes available to us. More details are available in the internal handbook.

TLDR: We receive a snapshot replica twice per day and refresh our Data Platform (Snowflake) data accordingly. This explains the significant delay in data refreshment.

Project Siphon - Real-time Solution: We’re working on Change Data Capture (CDC) on Postgres to stream data directly to endpoints like Snowflake and ClickHouse. This project is currently in POC phase with 10 tables and will expand beyond that scope.

Alternative Data Setup

To address these GitLab.com data availability limitations, we’ve implemented and validated an alternative setup using:

• BigQuery for data storage and querying with partitioned tables and 6-month retention
• Grafana for visualization and alerting with official BigQuery plugin
• Ruby components for data ingestion and programmatic API access
• Direct data ingestion for real-time data feeds (bypassing GitLab.com snapshot dependency)

Proven Capabilities (validated through CI cache analytics PoC):

• ✅ Near-real-time data: <5 minutes vs GitLab.com snapshot-dependent delay
• ✅ Easy alerting: Grafana dashboard with Slack alerts configured
• ✅ Programmatic API access: Ruby BigQuery client working
• ✅ Data aggregation: SQL analytics and time-series analysis functional
• ✅ Cost monitoring: Built-in BigQuery cost estimation and tracking

This setup enables faster iteration cycles and real-time monitoring capabilities by collecting data directly rather than waiting for GitLab.com snapshot availability.

Data Platform Decision Framework

Use this decision tree to determine the appropriate data platform for your use case:

flowchart TD
    A[Data Platform Decision] --> B{Need near-real-time data?}

    B -->|YES| C{Need alerting?}
    B -->|NO| D{Data already in Snowflake?}

    C -->|YES| E[BigQuery + Grafana]
    C -->|NO| F[BigQuery + Grafana]

    D -->|YES| G{Can accept GitLab.com snapshot delay?}
    D -->|NO| H{Can accept GitLab.com snapshot delay?}

    G -->|YES| I{Need alerting capabilities?}
    G -->|NO| J[BigQuery + Grafana]

    H -->|YES| K[Internal Events]
    H -->|NO| L[BigQuery + Grafana]

    I -->|YES| M[Grafana with Snowflake or BigQuery + Grafana]
    I -->|NO| N[Snowflake or Internal Events]

    style E fill:#e1f5fe
    style F fill:#e1f5fe
    style J fill:#e1f5fe
    style L fill:#e1f5fe
    style M fill:#fff3e0
    style N fill:#e8f5e8
    style K fill:#e8f5e8

Legend:

• 🔵 Blue: BigQuery + Grafana (proven solution)
• 🟡 Orange: Mixed approach (Snowflake + Grafana)
• 🟢 Green: Snowflake only (when requirements align)

Path to Consolidation

If the GitLab.com data availability constraints are addressed, we should consolidate to a single platform to align with company standards and reduce maintenance overhead.

Current Improvement Initiatives:

Requirement Gap	Initiative	Status	Link
GitLab.com Data Latency	🚀 Project Siphon - Change Data Capture (CDC) on Postgres to stream data directly to Snowflake and ClickHouse	🔄 In Progress (POC with 10 tables, expanding scope)	Issue #156
Custom Data Latency	⚡ Increase ingestion frequency for non-GitLab.com data sources	💡 Possible (GCS streaming already supported)	Issue #156
Self-service Access	🔓 Enable Snowflake access by default for all GitLab team members	📝 Proposed	Issue #22919
Email/Slack Alerts	📊 Set up Snowflake as Grafana data source for alerting	📝 Proposed	GDK Issue #2795
Programmatic API	🔑 Snowflake service accounts process	✅ Available	Handbook Process

When to Reassess

We should evaluate platform capabilities and reassess our data infrastructure decisions once every quarter, particularly monitoring the progress of Project Siphon’s real-time data streaming capabilities.