Cloud Connector Group

Vision

Make it easy to build a feature into GitLab across multiple types of deployment

Mission

GitLab Cloud Connector is a way to access services common to multiple GitLab deployments, instances, and cells. GitLab customers can choose between the following deployment options:

  • GitLab.com’s multi-tenant SaaS offering.
  • Deploying their own self-managed GitLab instance.
  • Signing up for GitLab Dedicated, our managed single-tenant solution.

The goal of GitLab Cloud Connector is to ensure that GitLab features can work equally across all three. This aligns with Enablement’s mission of accelerating other product groups by reducing the friction of developing for multiple deployments.

You can check our direction page for more information on our mission, and our short term and long term roadmap.

Team Members

The following people are permanent members of the Cloud Connector group:

Name Role
Paul John PhillipsPaul John Phillips Backend Engineering Manager, Cloud Connector
Aleksei LipniagovAleksei Lipniagov Senior Backend Engineer, Cloud Connector
Matthias KäpplerMatthias Käppler Staff Backend Engineer, Cloud Connector
Nikola MilojevicNikola Milojevic Senior Backend Engineer, Cloud Connector
Roy ZwambagRoy Zwambag Backend Engineer, Cloud Connector

Stable Counterparts

The following members of other functional teams are our stable counterparts:

Name Role
Roger WooRoger Woo Senior Product Manager, Cloud Connector and Database
Sacha GuyonSacha Guyon Senior Product Manager, Cloud Connector

Meetings

Where we can we follow the GitLab values and communicate asynchronously. However, there have a few important recurring meetings. Please reach out to the #g_cloud_connector Slack channel if you’d like to be invited.

  • Weekly Cloud Connector group meeting - Mondays 4:00PM UTC (3:00PM UTC during daylight savings time)
  • Cloud Connector group Office Hours
    • Tuesdays and Thursdays at 10:00AM UTC ( 09:00AM UTC during daylight savings time)

Work

We follow the GitLab engineering workflow guidelines. To bring an issue to our attention please create an issue in the relevant project, or in the Cloud Connector team project. Add the ~"group::cloud connector" label along with any other relevant labels. If it is an urgent issue, please reach out to the Product Manager or Engineering Manager listed in the Stable Counterparts section above.

Planning

When planning for a milestone, the Cloud Connector group creates a planning issue to discuss the upcoming milestone asynchronously. We outline the major efforts planned for the milestone along with who is working on each effort. Often there are individual issues that are either operational in nature, or don’t belong to an epic. These issues are also called out in the planning issue for prioritization.

We have three main boards for tracking our work (listed below).

Boards

Cloud Connector by Milestone The Milestone board gives us a “big picture” view of issues planned in each milestone.

Cloud Connector: Build The build board gives you an overview of the current state of work for "group::cloud connector". These issues have already gone through validation and are on the Product Development Build Track. Issues are added to this board by adding the cloud connector::active and "group::cloud connector" labels. Issues in the workflow::ready for development column are ordered in priority order (top down). Team members use this column to select the next item to work on.

Cloud Connector: Validation The validation board is a queue for incoming issues for the Product Manager to review. A common scenario for the Cloud Connector group’s validation board is when an issue is created that requires further definition before it can be prioritized. The issue typically states a big picture idea but is not yet detailed enough to take action. The Cloud Connector group will then go through a refinement process to break down the issue into actionable steps, create exit criteria and prioritize against ongoing efforts. If an issue becomes too large, it will be promoted to an epic and small sub-issues will be created.

Say/Do Ratio

We use the ~Deliverable label to track our Say/Do ratio. At the beginning of each milestone, during an Cloud Connector group Weekly meeting, we review the issues and determine those issues we are confident we can deliver within the milestone. The issue will be marked with the ~Deliverable label. At the end of the milestone the successfully completed issues with the ~Deliverable label are tracked in two places. We have a dashboard in Sisense that will calculate how many were delivered within the milestone and account for issues that were moved. Additionally, our milestone retro issue lists all of the ~Deliverable issues shipped along with those that missed the milesone.

Roadmap

The Cloud Connector group’s Roadmap gives a view of what is currently in flight as well as projects that have been prioritized for the next 3+ months.

Knowledge sharing and lessons learned

Blog posts (when team was working as Application Performance)

More about how we work

Dashboards


Application Performance Group - 2020 Impact

Application Performance Group - 2020 Impact

The year 2020 marked the first full year for the Application Performance group. The origins of the Application Performance group began in early 2019, with the most recent team members joining in October of 2019. This summary is intended to highlight the impact and the work of the Application Performance group in 2020. The sections below will give a brief overview of the project, describe the impact and link to issues and epics, mostly within the GitLab.org project. The efforts listed are in approximate chronological order. This is also not to be considered a comprehensive list. There are some isolated issues as well as confidential initiatives that are not listed below.

Application Performance Group - Approach and Common Themes

How we approach a performance problem

We’re a cross-functional group, which means that we frequently need to venture into unknown territory, both in terms of product areas but also technology. This comes with a certain amount of unknowns each time we do this, but nevertheless we think there are certain steps that apply to most of the problems we look at, which are summarized below. These steps will not always happen in the same order, but they should be carried out in one way or another in most cases.

Application Performance Group - Knowledge Sharing

Knowledge Sharing

Early in the days of the Application Performance group’s formation we started an issue to share memory domain articles, books and resources within our group and GitLab. We are moving some of these resources to a shared handbook page. We aim to update this frequently.

Our approach to performance problems

We are life-long learners and every new challenge we take on means lessons were learned, and we think that other teams can benefit from us documenting these.

Last modified August 16, 2024: Replace aliases with redirects (af33af46)