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:
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
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 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.
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.
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.
Paul John Phillips
Aleksei Lipniagov
Matthias Käppler
Nikola Milojevic
Roy Zwambag