Geo is a Premium feature, built to help speed up the development of distributed teams by providing one or more read-only mirrors of a primary GitLab instance. This mirror (a Geo secondary node) reduces the time to clone or fetch large repositories and projects, or can be part of a Disaster Recovery solution.
| Person | Role |
|---|---|
| Ameya Darshan | Security Engineer, Deploy:Environments, Systems:Gitaly, Systems:Geo, Delivery, Snippets |
| Nick Westbury | Senior Software Engineer in Test, Core Platform:Geo |
Our priorities are aligned with the product direction. You can read more about this on the Geo Product Vision page.
Alongside the items listed in our Product Vision, we need to constantly assess issues that our customers bring to our attention. These could take the form of bug reports or feature requests. Geo users are often our largest customers and some rely on Geo as a critical part of their workflow.
We also work constantly to keep housekeeping chores to a manageable level. Where possible, we address these issues as part of a related project. Where this is not possible, we use time around our projects to make this happen.
Every quarter the engineering team sets objectives and key results. OKRs are managed in GitLab as of FY24-Q1. The following are links to issues lists for Geo's OKRs.
Disaster Recovery (DR) is a set of policies, tools and procedures put in place to be able to recover from a disaster.
Geo provides data redundancy. The customer will have a redundant copy of data in a separate location. If anything were to happen to their primary instance, a secondary instance still retains a copy of the data.
However, data redundancy is only one part of a complete DR strategy.
High Availability (HA) is also a step towards Disaster Recovery. At the moment Geo does not provide true HA because if the primary instance is not available, certain actions are not possible.
The first line of support will always be the support engineer assigned to the issue raised by the customer. However at times more expertise is required to resolve the customer concern and a Geo engineer needs to be involved. This section outlines the process and expectations when requesting support from the team for Geo-related customer support issues.
Before submitting a request for support, please review Geo's documentation, the Disaster Recovery docs, the Geo Handbook pages, or search through previous customer issues in the Geo Customers Project. The answer to your questions might be found there.
If you have a general question for which you can't find your answer, then feel free to ask your question in the #g_geo channel on Slack. Please keep in mind that engineers will do their best to support you and answer your question from the top of their heads. If they need to do more research and/or address more complicated scenarios, you will need to create a support issue (see next section).
We like to use issues when customers need help from the Geo Team. This helps us to prioritize work and make sure that we don't lose history and maintain context when the Slack retention policy activates. We ask requestors to create an issue in the Geo Customers Project.
Please make sure to use and fill the support request issue template. As the requestor you only need to fill the Customer Info and Support Question sections. The Timeline and Retrospective sections will be filled by the Geo team members as they address your request.
If you like, you may assign a priority label to your request. A geo team member or the PM will review this priority assignment during the triage of the issue. Please use the table below as a reference of priority levels and expected response times.
| Priority | Typically used for | Expected first response time |
|---|---|---|
| P4 | General questions that can't be answered on slack by Geo engineers of the top of their heads and will require a bit more investigation. | 2-3 days |
| P3 | Customer problems that are not time sensitive (i.e. they have an easy work around) or scheduling time to engage with the customer in the future for them to achieve their goals. | 1 day |
| P2 | Customer problems that are somewhat time sensitive and are blocking decisions or progress to be made on the customer side. | 1/2 day |
| P1 | Fires and emergencies that the customer is experiencing | 1-2 hours |
* Response times are based on weekdays (excluding holidays) within regular business hours in the time zones that team members are located.
* Outages and other urgent matters should be channeled through GitLab's incident management processes.
The following links lead to Geo team lists of issues to help with identifying missing subtype labels. After opening each link, select the desired milestone filter.
#g_geo
chat channel for questions that don't seem appropriate to use the issue tracker
for.Our planning and build process is recorded on the process page.
The demos are recorded and should be stored in Google Drive under "GitLab Recorded Videos –> Geo Demos". If you recorded the demo, please make sure the recording ends up in that folder.
See the Geo Glossary.
(Sisense↗) We also track our backlog of issues, including past due security and infradev issues, and total open System Usability Scale (SUS) impacting issues and bugs.
(Sisense↗) MR Type labels help us report what we're working on to industry analysts in a way that's consistent across the engineering department. The dashboard below shows the trend of MR Types over time and a list of merged MRs.
(Sisense↗) Flaky test are problematic for many reasons.
(Sisense↗) Slow tests are impacting the GitLab pipeline duration.