Cloud Connector Group
Vision
Make it easy to build a feature into GitLab across multiple types of deployment.
We have formalized our technical vision in a separate vision document, a living document that we
commit to revisiting at least once a year.
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:
Stable Counterparts
The following members of other functional teams are our stable counterparts:
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.
Links
2024 Cloud Connector Team Impact Overview
Knowledge sharing and lessons learned
Blog posts (when team was working as Application Performance)
More about how we work
Dashboards
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.
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.
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.
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.
Objective
Until today, Cloud Connector has delivered value primarily by expanding the Duo addressable market from multi-tenant gitlab.com to single-tenant Dedicated and self-managed environments. However, there are clear opportunities to improve our platform and
expand our reach in the following areas:
- From cloud-hosted to self-hosted. There is demand for supporting self-hosted or hybrid single-tenant setups, where a service such as the AI gateway connected through Cloud Connector runs on premises. This is especially important to serve air-gapped environments.
- Streamline AI feature development. Help to simplify development, reducing maintenance costs, and enabling feature teams to build autonomously. This foundation will address current AI needs and support future expansion to non-AI use cases.
- From AI to any use case. There is demand to deliver non-AI use cases such as Advanced SAST through Cloud Connector.
This creates a complex matrix of setups and use cases, which today requires bespoke solutions and raises ownership questions as we continue to expand our product offerings.
Moreover, because Cloud Connector operates both at the infrastructure and application level, we take on a wide range of responsibilities regardless of the feature
being integrated.
Paul John Phillips
Aleksei Lipniagov
Matthias Käppler
Nikola Milojevic
Roy Zwambag