Skip to content
Snippets Groups Projects
Commit f6f8eceb authored by Julie Manalo's avatar Julie Manalo
Browse files

Merge branch 'master' into 'patch-19826111318' 

# Conflicts:
#   source/handbook/sales/territories/index.html.md
parents 2fadc43d dc3926ec
No related branches found
No related tags found
No related merge requests found
Hide whitespace changes
Inline Side-by-side
Showing
with 373 additions and 136 deletions
source/handbook/customer-success/tam/health-scores/index.html.md
+ 1
− 1
View file @ f6f8eceb
@@ -28,7 +28,7 @@ title: "Customer Health Scores"
 
In order to manage customers at scale we must have a consistent way of keeping track of customer details including the current “health” of the customer. The health of a customer is affected by many different factors including product usage, support interactions, internal budgets, and TAM communication.
 
The current health of a customer is also directly related to the customer’s journey with GitLab. Because of this, customer health and the running communication notes between a TAM and the customer should be closely linked. Since the primary location for recording customer health scores is in Salesforce, the running call notes should also be available in this location. For additional information, watch a short video on [updating Customer Health](https://www.youtube.com/watch?v=2j8ACuQksEo&feature=youtu.be&hd=1) and review the [Customer Health Dashboard](https://gitlab.my.salesforce.com/01Z4M000000skuA).
The current health of a customer is also directly related to the customer’s journey with GitLab. Because of this, customer health and the running communication notes between a TAM and the customer should be closely linked. Since the primary location for recording customer health scores is in Salesforce, the running call notes should also be available in this location. For additional information, watch a short (private- [watch as GitLab Unfiltered](https://www.youtube.com/watch?v=LKZ23pRfpBg) ) video on [updating Customer Health](https://www.youtube.com/watch?v=2j8ACuQksEo&feature=youtu.be&hd=1) and review the [Customer Health Dashboard](https://gitlab.my.salesforce.com/01Z4M000000skuA).
 
See [Health Scoring Criteria](/handbook/customer-success/tam/triage/#health-scoring-criteria).
 
source/handbook/customer-success/tam/onboarding/index.html.md
+ 0
− 2
View file @ f6f8eceb
@@ -37,8 +37,6 @@ Once an account has been assigned to a Technical Account Manager, they must open
 
The goal of the issue template is to help Technical Account Managers more consistently deliver a more thorough onboarding experience for customers, so they are set-up for success. If an item in the checklist doesn't make sense for a particular customer, mark it complete and leave a note in the comments.
 
In order to complete the onboarding object, the onboarding survey _must_ be sent to the customer. Be sure to send a personalised email to the team of people in the customer's organization that you have been working with throughout the onboarding time-box: [Here is the link to the survey](https://goo.gl/forms/aYOLCCkdM52yfaaD3).
An overview of these tools is [recorded in this video](https://www.youtube.com/watch?v=JLTvuTSycnQ&feature=youtu.be&hd=1) (Private Gitlab Unfiltered link).
 
## Customer Support
source/handbook/eba/index.html.md
+ 1
− 1
View file @ f6f8eceb
@@ -20,7 +20,7 @@ This page details processes and general guidelines specific to the Executive Bus
* Jaclyn Grant (Sr. EBA) supporting Paul Machle, CFO
* Vanessa Wheeler (EBA) supporting Scott Williamson (VP of Product), Mark Pundsack (VP of Product Strategy) and Eric Johnson (VP Engineering)
* Trevor Knudsen (EBA) supporting Sung Hae Kim (CPO), Dave Gilbert (VPR), and Carol Teskey (Director, Global People Ops)
* Katie Gammon (EBA) supporting David Hong (VP of Field Operations), David Sakamoto (VP of Customer Success), Ryan O’Nell (VP of Commercial Sales), Mike Pyle (VP of Enterprise Sales), Brandon Jung (VP of Alliances)
* Katie Gammon (EBA) supporting David Hong (VP of Field Operations), David Sakamoto (VP of Customer Success), Ryan O’Nell (VP of Commercial Sales), Mike Pyle (VP of Enterprise Sales), Brandon Jung (VP of Alliances), Michelle Hodges (VP of Worldwide Channels)
 
## Meeting request requirements
 
source/handbook/engineering/dev-backend/gitaly/index.html.md
+ 16
− 0
View file @ f6f8eceb
@@ -31,3 +31,19 @@ The goals of Gitaly are
1. Optimize git services using caching
 
See [the design document](https://gitlab.com/gitlab-org/gitaly/tree/master#reason) for an in-depth explanation behind the motivation for GitLab.
### Process
#### Onboarding
When a new developer joins Gitaly, their resposibility will include maintaining
the Gitaly project from their first day. This means that the developer will get
`Maintainer` access to the repository and will be added to the
`gitlab.com/gl-gitaly` group so they appear in merge request approval group.
#### Retrospectives
At the beginning of each release, the Gitaly EM will create a retrospective issue
to collect discussion items during the release. The first weekly Gitaly meeting
after the 18th that issue will be used to discuss what was brought up.
source/handbook/engineering/development/ci-cd/package/index.html.md.erb
+ 8
− 2
View file @ f6f8eceb
@@ -59,7 +59,7 @@ Our team emphasises ownership by people who have information required. This mean
 
### Workflow
 
Our Product Manager owns the problem validation backlog and problem validation process as outlined in the [Product Development Workflow](https://about.gitlab.com/handbook/product-development-flow/). Our Product Designer then owns the [solution validation](https://about.gitlab.com/handbook/product-development-flow/#validation-phase-3-solution-validation) process. You can view all items and their current state in the [Package: Validation Track](https://gitlab.com/groups/gitlab-org/-/boards/1397751?&label_name[]=group%3A%3Apackage) issue board.
Our Product Manager owns the problem validation backlog and problem validation process as outlined in the [Product Development Workflow](https://about.gitlab.com/handbook/product-development-flow/). Our Product Designer then owns the [solution validation](https://about.gitlab.com/handbook/product-development-flow/#validation-phase-3-solution-validation) process. You can view all items and their current state in the [Package: Validation Track](https://gitlab.com/groups/gitlab-org/-/boards/1397751?&label_name[]=group%3A%3Apackage) issue board.
 
At the end of this process, the issues will be ready for the [build track](https://about.gitlab.com/handbook/product-development-flow/#build-track) which is owned by the Product Developers and lives in the [Package:Workflow](https://gitlab.com/groups/gitlab-org/-/boards/1284221?label_name[]=group%3A%3Apackage) issue board.
 
@@ -71,6 +71,12 @@ The Product Manager owns the process of populating the current milestone with fe
 
Issues that we're actually expecting to work on will have the `package:active` label added to them at which point they'll appear in the Package:Workflow board. As product developers begin working on the issue, they'll assign the `workflow:in dev` label.
 
### Code Review
Code reviews follow the standard process of using the [reviewer roulette](https://docs.gitlab.com/ee/development/code_review.html#reviewer-roulette) to choose a reviewer and a maintainer. The roulette is optional, so if a merge request contains changes that someone outside our group may not fully understand in depth, it is encouraged that a member of the package team be chosen for the preliminary review to focus on correctly solving the problem. The intent is to leave this choice to the discretion of the engineer but raise the idea that fellow package team members will sometimes be best able to understand the implications of the features we are implementing. The maintainer review will then be more focused on quality and code standards.
This tactic also creates an environment to ask for early review on a WIP merge request where the solution might be better refined through collaboration and also allows us to share knowledge across the team.
### Async Daily Standups
 
The purpose of the daily standup is to allow team members to have visibility into what everyone else is doing, allow a platform for asking for and offering help, and provide a starting point for some social conversations. We use [geekbot](https://geekbot.com/) integrated with Slack.
@@ -98,7 +104,7 @@ Examples of our retrospectives can be found here: [https://www.youtube.com/chann
### Issue Weighting
 
| Weight | Description |
| --- | --- |
| --- | --- |
| 1: Trivial | The problem is very well understood, no extra investigation is required, the exact solution is already known and just needs to be implemented, no surprises are expected, and no coordination with other teams or people is required.<br><br>Examples are documentation updates, simple regressions, and other bugs that have already been investigated and discussed and can be fixed with a few lines of code, or technical debt that we know exactly how to address, but just haven't found time for yet.<br><br>This will map to a confidence greater or equal to 90%. |
| 2: Small | The problem is well understood and a solution is outlined, but a little bit of extra investigation will probably still be required to realize the solution. Few surprises are expected, if any, and no coordination with other teams or people is required.<br><br>Examples are simple features, like a new API endpoint to expose existing data or functionality, or regular bugs or performance issues where some investigation has already taken place.<br><br>This will map to a confidence greater than or equal to 75%. |
| 3: Medium | Features that are well understood and relatively straightforward. A solution will be outlined, and most edge cases will be considered, but some extra investigation will be required to realize the solution. Some surprises are expected, and coordination with other teams or people may be required.<br><br>Bugs that are relatively poorly understood and may not yet have a suggested solution. Significant investigation will definitely be required, but the expectation is that once the problem is found, a solution should be relatively straightforward.<br><br>Examples are regular features, potentially with a backend and frontend component, or most bugs or performance issues.<br><br>This will map to a confidence greater than or equal to 60%. |
source/handbook/engineering/development/database/index.html.md.erb
+ 1
− 0
View file @ f6f8eceb
@@ -57,6 +57,7 @@ If you're interested in participating in database reviews, please start from cre
* I. Ahmed, G. Smith et al: "[PostgreSQL 10 High Performance: Expert techniques for query optimization, high availability, and efficient database maintenance.](https://www.amazon.com/dp/1788474481)" (2018)
* Hans-Jürgen Schönig: "[Mastering PostgreSQL 11](https://www.amazon.com/Mastering-PostgreSQL-techniques-fault-tolerant-applications/dp/1789537819)" (2018)
* Markus Winand: "[SQL Performance Explained](https://sql-performance-explained.com/)"
* Dimitri Fontaine: "[The Art of PostgreSQL](https://theartofpostgresql.com/)"
 
##### Other resources
 
source/handbook/engineering/development/enablement/distribution/maintenance/arm.html.md 0 → 100644
+ 76
− 0
View file @ f6f8eceb
---
layout: handbook-page-toc
title: "Distribution Team Infrastructure: ARM"
---
## On this page
{:.no_toc .hidden-md .hidden-lg}
- TOC
{:toc .hidden-md .hidden-lg}
## Hardware Provider
[Scaleway][scaleway] is the current provider for ARM runner instances. All
[distribution][distribution] team members should be able to log into the
provider using the credentials stored in **1Password**.
## Teams Working on ARM Related Tasks
Several GitLab teams collaborate to provide support for ARM:
1. [Distribution][distribution] manages the [ARM runner provider][scaleway]
and issues with build pipelines.
1. [Community Advocates][advocates] answer questions and provide community support in the forums.
1. [Verify CI][verify-ci] would help build packages for ARM runners.
## Failure Notifications
Build failures for master, stable branches, and tags are sent to the
[distribution][distribution] team slack channel. Developers receive failure
notices via e-mail for pipelines triggered from their feature branches as
they would normally for any other branch.
## Known Issues with ARM Builders
- Slow speeds cause issues because of runner [issues handling timeouts][timeout-blog].
- [Scaleway Docker Driver][scaleway-driver] has recurring issues.
- Sometimes the ARM machines just shut down arbitrarily.
- Machines fall into a ***shut down*** state that count against the runner
cap but are not actually functional.
[Follow the procedure for pending builds][pending-builds] when this happens.
## Frequently Asked Questions
### Why don't you compile ARM32 bit packages on ARM64 for speed?
We explored cross compiling and found that the challenges caused outweighed
the benefits provided. The process would take a lot of deep investigation to
overcome those challenges.
### How do the ARM Builders get provisioned?
ARM builders are provisioned up to the maximum cap of concurrent machines at
all times. The ARM builders take a fair amount of time to spin up; permanent
provision increases their availability for pipelines. Continuous Integration
will automatically provision another ARM builder if one of them is properly
shut down. [Quota usage is visible in the Scaleway account profile][quotas]
and the [hard cap on runners is set in the ops cookbooks][cap-setting].
### What GitLab packages get built for Raspberry Pi?
Due to [memory requirements] we do not currently recommend the Raspberry Pi
as a production platform. Due to this, we only build packages for the
Community Edition.
[scaleway]: https://www.scaleway.com/en/virtual-instances/arm-instances/
[verify-ci]: /handbook/engineering/development/ci-cd/verify/
[distribution]: /handbook/engineering/development/enablement/distribution/
[advocates]: /handbook/marketing/community-relations/community-advocacy/
[timeout-blog]: https://about.gitlab.com/blog/2019/11/15/tracking-down-missing-tcp-keepalives/
[scaleway-driver]: https://github.com/scaleway/docker-machine-driver-scaleway
[pending-builds]: /handbook/engineering/development/enablement/distribution/maintenance/build-machines.html#when-builds-are-pending-on-devgitlaborg
[memory requirements]: https://docs.gitlab.com/ee/install/requirements.html#memory
[quotas]: https://console.scaleway.com/account/profile
[cap-setting]: https://ops.gitlab.net/gitlab-cookbooks/chef-repo/blob/56d8ce707368fbd529233213d6bb2624b28c13ee/roles/build-runners-gitlab-org.json#L145
source/handbook/engineering/development/enablement/distribution/maintenance/build-machines.html.md
+ 3
− 0
View file @ f6f8eceb
@@ -54,6 +54,7 @@ It spins up three types of machines:
 
1. ARM machines for building Raspberry Pi packages. They are `C1` machines
spawned inside Scaleway using `scaleway` docker-machine driver.
[See the specific documentation for ARM support information][arm].
 
#### build-trigger-runner-manager.gitlab.org
 
@@ -134,3 +135,5 @@ are:
docker-machine ls | grep -v 'Running' | awk '{print $1}' | xargs docker-machine rm --force
```
will remove all machines that do not have `Running` state.
[arm]: /handbook/engineering/development/enablement/distribution/maintenance/arm.html
source/handbook/engineering/development/enablement/ecosystem/index.html.md.erb
+ 6
− 0
View file @ f6f8eceb
@@ -38,6 +38,12 @@ The following members of other functional teams are our stable counterparts:
Whenever possible, we prefer to communicate asynchronously using issues, merge requests, and Slack. However, face-to-face meetings are useful to establish personal connection and to address items that would be more efficiently discussed synchronously such as blockers.
* Weekly Ecosystem product and engineering meeting - Wednesdays 11:00am CST/16:00 UTC
* Note that the weekly meeting schedule will undergo some iteration as new team members come on board. Meetings will be recorded and everyone is encouraged to watch the meeting on our [GitLab Unfiltered playlist](https://www.youtube.com/playlist?list=PL05JrBw4t0KpoFo2QyceT_4CNfcq7do4s) if they are not able to attend.
* Async Standups - Daily in Slack [#g_ecosystem](https://gitlab.slack.com/messages/CK4Q4709G)
* We use the [Geekbot Slack plugin](https://geekbot.com/dashboard/) to prompt team members for async updates. The intention of these updates is to provide visibility and to bring up anything slowing or blocking progress. There is a weekly social question on Monday for team members to share any highlights from the weekend.
* Prompts:
* Highlight something you did today.
* Anything slowing/blocking your progress?
* Tell us about something fun or interesting you did outside of work last week/weekend. (Mondays only)
 
## Workflow
 
source/handbook/engineering/development/growth/acquisition/index.html.md.erb
+ 66
− 1
View file @ f6f8eceb
@@ -19,7 +19,7 @@ and is responsible for promoting the value of GitLab and accelerating site visit
Questions should start by @ mentioning the Product Manager for the [Acquisition group](/handbook/product/categories/#acquisition-group)
or create an issue in the [Growth issues board].
 
### How we work
## How we work
 
* We're data savvy
* In accordance with our [GitLab values]
@@ -27,6 +27,71 @@ or create an issue in the [Growth issues board].
* We get a chance to work on the things we want to work on
* Everyone can contribute; no silos
 
## Workflow
We use the [Engineering workflow](/handbook/engineering/workflow/) when working on issues and
merge requests across multiple projects.
### Timeline
We plan in monthly cycles using [milestones](https://docs.gitlab.com/ee/user/project/milestones/) following the [Product development timeline](/handbook/engineering/workflow/#product-development-timeline). To ensure we adhere to this monthly cycle, we pay special attention to these dates:
* `M-1, 13th`: Milestone commitment finalized
* `M-1, 18th`: Begin milestone
* `M, 17th`: End milestone
* `M, 19th`: Begin group retro
* `M, 22nd`: Release day
* `M, 26th`: End group retro
### Planning and Prioritization
We plan and groom issues in advance of finalizing a milestone commitment on `M-1, 13th` and before beginning development on `M-1, 18th`.
We tag each issue with the correct milestone, viewable on the [milestone board](https://gitlab.com/groups/gitlab-org/-/boards/1370834?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=devops%3A%3Agrowth&label_name[]=group%3A%3Aacquisition)
At times a single deliverable will be broken in to mutliple issues. One of these issues should be labelled as the `Deliverable` while the other issues are dependencies and are linked to the `Deliverable` issue. Once all dependency issues have been delivered, the issue with the `Deliverable` label can be closed. Deliverables by milestone are viewable on the [milestone deliverables board](https://gitlab.com/groups/gitlab-org/-/boards/1370834?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=devops%3A%3Agrowth&label_name[]=group%3A%3Aacquisition&label_name[]=Deliverable).
Prioritization is a collaboration between Product, UX, Data, and Engineering. We use the
[ICE framework](/direction/growth/#growth-ideation-and-prioritization) for experiments. Each `Deliverable` issue will have an ICE score.
### Tracking Milestone Progress
Our primary method of tracking milestone progress is through our [workflow board](https://gitlab.com/groups/gitlab-org/-/boards/1158847?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=devops%3A%3Agrowth&label_name[]=group%3A%3Aacquisition). We keep all issues up to date with the correct workflow labels. Any time the status of an issue changes, we add a detailed comment in each issue providing additional context.
### Measuring Engineering Throughput
One of our main engineering metrics is [throughput](https://about.gitlab.com/handbook/engineering/management/throughput/) which is the total number of MRs that are completed and in production in a given period of time. We use throughput to encourage small MRs and to practice our values of [iteration](https://about.gitlab.com/handbook/values/#iteration). Read more about [why we adoped this model](https://about.gitlab.com/handbook/engineering/management/throughput/#why-we-adopted-this-model).
We aim for 10 MRs per engineer per month which is tracked using our [throughput metrics dashboard](https://app.periscopedata.com/app/gitlab/559676/Growth:Acquisition-and-Conversion-Development-Metrics).
### Daily Standups (Async)
We have daily asynchronous standups using [status hero's](https://statushero.com/integrations/gitlab) Slack integration. The purpose of these standups are to allow team members to have visibility into what everyone else is doing, allow a platform for asking for and offering help, and provide a starting point for some social conversations.
Three questions are asked at each standup:
* How do you feel today?
* What are you working on today?
* Our status updates consist of the various issues and merge requests that are currently being worked on. If the work is in progress, we provide the estimated percentage complete.
> `!12345 - 50% complete` - Working on tests and refactoring
* Any blockers?
* We raise any blockers early and ask for help.
### Meetings (Sync)
We hold synchronus meetings twice a week on Mondays 03:30pm UTC and Wednesdays 03:30pm UTC. These meetings are used to additional gain clarity and alignment on our async discussions.
* In Development
* Blockers
* Existing Experiments
* Planning
* Grooming
* Design Review
* Estimation
* Milestone Commitments
* Retro
* What went well
* What didn’t go well
* What can be improved
## Team Members
 
The following people are permanent members of the Acquisition Group:
source/handbook/engineering/development/growth/be-fulfillment/index.html.md.erb
+ 1
− 1
View file @ f6f8eceb
@@ -112,7 +112,7 @@ graph TD;
C --> D(Auto deploy to production in 3 hours);
```
 
If something goes wrong at the `Verification` stage, we could create an issue with the label `production::blocker`, which will prevent deployment to production.
If something goes wrong at the `Verification` stage, we could create an issue with the label `production::blocker`, which will prevent deployment to production. The issue cannot be confidential.
 
For MRs with significant changes, we should consider using [feature flags](https://gitlab.com/gitlab-org/customers-gitlab-com/#feature-flags) or create an issue with the `production::blocker` label to pause deployment and a allow for longer testing.
 
source/handbook/engineering/development/growth/expansion/index.html.md.erb
+ 16
− 2
View file @ f6f8eceb
@@ -36,8 +36,22 @@ merge requests across multiple projects.
 
#### Prioritization
 
Prioritization is a collaboration between Product, UX, Data, and Engineering. We use the
[ICE framework](/direction/growth/#growth-ideation-and-prioritization) for experiments.
Prioritization is a collaboration between Product, UX, Data, and Engineering.
* We use the [ICE framework](/direction/growth/#growth-ideation-and-prioritization) for experiments.
* We use [Priority](https://docs.gitlab.com/ee/development/contributing/issue_workflow.html#priority-labels)
and [Severity](https://docs.gitlab.com/ee/development/contributing/issue_workflow.html#severity-labels) labels for bugs.
### Estimation
| Weight | Description (Engineering) |
| ------ | ------ |
| 1 | Trivial: The simplest possible change. We are confident there will be no side effects. |
| 2 | Small: A simple change (minimal code changes), where we understand all of the requirements. |
| 3 | Medium: A simple change, but the code footprint is bigger (e.g. lots of different files, or tests effected). The requirements are clear. |
| 5 | Large: A more complex change that will impact multiple areas of the codebase, there may also be some refactoring involved. Requirements are understood but you feel there are likely to be some gaps along the way. |
Anything over a 5 (large) indicates the work should be broken down into smaller, clearly defined issues.
 
#### Tracking
 
source/handbook/engineering/development/growth/retention/index.html.md.erb
+ 16
− 2
View file @ f6f8eceb
@@ -36,8 +36,22 @@ merge requests across multiple projects.
 
#### Prioritization
 
Prioritization is a collaboration between Product, UX, Data, and Engineering. We use the
[ICE framework](/direction/growth/#growth-ideation-and-prioritization) for experiments.
Prioritization is a collaboration between Product, UX, Data, and Engineering.
* We use the [ICE framework](/direction/growth/#growth-ideation-and-prioritization) for experiments.
* We use [Priority](https://docs.gitlab.com/ee/development/contributing/issue_workflow.html#priority-labels)
and [Severity](https://docs.gitlab.com/ee/development/contributing/issue_workflow.html#severity-labels) labels for bugs.
### Estimation
| Weight | Description (Engineering) |
| ------ | ------ |
| 1 | Trivial: The simplest possible change. We are confident there will be no side effects. |
| 2 | Small: A simple change (minimal code changes), where we understand all of the requirements. |
| 3 | Medium: A simple change, but the code footprint is bigger (e.g. lots of different files, or tests effected). The requirements are clear. |
| 5 | Large: A more complex change that will impact multiple areas of the codebase, there may also be some refactoring involved. Requirements are understood but you feel there are likely to be some gaps along the way. |
Anything over a 5 (large) indicates the work should be broken down into smaller, clearly defined issues.
 
#### Tracking
 
source/handbook/engineering/development/index.html.md.erb
+ 8
− 13
View file @ f6f8eceb
@@ -100,21 +100,16 @@ quality, product management, and development.
 
### Rapid Action Issue
 
In cases where infrastructure needs a more general resolution to a problem, an
issue can be opened for "rapid action" (and labeling them `rapid action`). This is typically around a shared
infrastructure resource that is running towards capacity (as examples Postgres
and Redis). Often in these scenarios we need several teams to dig in and solve
smaller pieces of the problem to reduce load. In this situation, open an issue
with the title "XXXX rapid action", give a description of the general issue you
want to take pressure off of, and label the issue with infra/dev. If you know
the section/groups which need to focus, also include that. An example issue to
this process is the following: [Redis Rapid Action](https://gitlab.com/gitlab-com/www-gitlab-com/issues/4747).
Rapid Action, as the name implies, is the process we use when a critical situation arises needing immediate attention from various stakeholders. When the situation is identified as a potential Rapid Action the following guidance is recommended.
 
* Create an issue or epic labeled with `rapid action`
* Identify the stakeholders involved and cc them on the issue/epic
* Create a doc using [this](https://docs.google.com/document/d/1ZIJvWgo2W4Tw3mmXs_WDJK5Di-zfANtgYgiTZ5Afdyc/edit) template to track the progress of the rapid action
on a daily basis
* (Optional) create a slack room dedicated to this rapid action
* In the document and tracking issue list the context, stakeholders and exit criteria
 
Note: This process includes both escalating issues to be addressed immediately
as well as deferring issues that are not critical. When an issue is not
critical, it may be removed from the board by removing the `rapid action` status.
It is recommended that daily progress is updated in the agenda. Once the exit criteria has been met, remove the `rapid action` label, close the rapid action issue and prepend the agenda document with "Closed" or "Deprecated" to indicate its status.
 
### Email alias and roll-up
1. Available email alias (a.k.a. Google group):
source/handbook/engineering/development/ops/index.html.md.erb
+ 1
− 1
View file @ f6f8eceb
@@ -11,7 +11,7 @@ title: Ops Section
 
## Vision
 
...
The [Ops section](https://about.gitlab.com/direction/ops/) strives to make operational tasks easier for developers.
 
## Mission
 
source/handbook/engineering/development/ops/monitor/apm/index.html.md.erb
+ 2
− 0
View file @ f6f8eceb
@@ -87,6 +87,8 @@ As an engineer is available to start a new issue, he/she can self-assign the nex
 
### Workflow Labels
 
We use standard workflow labels on issues as described in the [product development flow](https://about.gitlab.com/handbook/product-development-flow/#build-phase-2-develop--test). Specifically we use `workflow::ready for development` when the issue has enough information to start development, `workflow::In dev` as we are working on the issue, `workflow::In review` when a merge request is in review, and `workflow::verification` after the merge request has been merged and we are testing the change in staging and production.
It is the responsibility of the assigned engineer for an issue to keep the workflow label up-to-date for the issue. We use the [APM Workflow](https://gitlab.com/groups/gitlab-org/-/boards/1165027) board to visualize the issues.
 
### Async Issue Updates
source/handbook/engineering/development/ops/monitor/health/index.html.md.erb
+ 107
− 0
View file @ f6f8eceb
@@ -49,6 +49,113 @@ This team maps to the [Health Group](/handbook/product/categories/#health-group)
* [Charts](https://gitlab.com/groups/gitlab-org/-/boards/1184016) - Issue board with all issues labeled "Charts"
* [Monitor Bugs](https://gitlab.com/groups/gitlab-org/-/boards/979406) - Issue board organized by Priority labels so that we make sure we meet our bug fix SLA
 
## Development Processes
### Surfacing blockers
To surface blockers, mention your Engineering Manager in the issues, and then contact them via slack and or 1:1's. Also make sure to raise any blockers in your daily async standup using Geekbot.
The engineering managers want to make unblocking their teams their highest priority. Please don't hesitate to raise blockers
### Scheduling
#### Scheduling issues in milestones
The Product Manager is responsible for scheduling issues in a given milestone. During the backlog grooming portion of our weekly meeting, all parties will make sure that issues are scoped and well-defined enough to implement and whether they need UX involvement and/or technical investigation.
As we approach the start of the milestone, Engineering Managers are responsible for adding the ~deliverable label to communicate which issues we are committing to finish in the given milestone. Generally, the Engineering Manager will use the prioritized order of issues in the milestone to determine which issues to label as ~deliverable. The Product Manager will have follow-up conversations with the Engineering Managers if the deliverables do not meet their expectations or if there are other tradeoffs we should make.
#### Scheduling bugs
When new bugs are reported, the engineering managers ensure that they have proper Priority and Severity labels. Bugs are discussed during our backlog grooming session and are scheduled according to severity, priority, and the capacity of the teams. Ideally, we should work on a few bugs each release regardless of priority or severity.
### Weekly async issue updates
Every Friday, each engineer is expected to provide a quick async issue update by commenting on their assigned issues using the following template:
```
<!---
Please be sure to update the workflow labels of your issue to one of the following (that best describes the status)"
- ~"workflow::In dev"
- ~"workflow::In review"
- ~"workflow::verification"
- ~"workflow::blocked"
-->
### Async issue update
1. Please provide a quick summary of the current status (one sentence).
1. When do you predict this feature to be ready for maintainer review?
1. Are there any opportunities to further break the issue or merge request into smaller pieces (if applicable)?
```
We do this to encourage our team to be more async in collaboration and to allow the community and other team members to know the progress of issues that we are actively working on.
### Interacting with community contributors
Community contributions are encouraged and prioritized at GitLab. Please check out the [Contribute page](/community/contribute/) on our website for guidelines on contributing to GitLab overall.
Within the Monitor stage, Product Management will assist a community member with questions regarding priority and scope. If a community member has technical questions on implementation, Engineering Managers will connect them with engineers within the team to collaborate with.
### Using spikes to inform design decisions
Engineers use spikes to conduct research, prototyping, and investigation to gain knowledge necessary to reduce the risk of a technical approach, better understand a requirement, or increase the reliability of a story estimate (paraphrased from [this overview](https://www.scaledagileframework.com/spikes/)). When we identify the need for a spike for a given issue, we will create a new issue, conduct the spike, and document the findings in the spike issue. We then link to the spike and summarize the key decisions in the original issue.
### Preparing UX designs for engineering
Product designers generally try to work one milestone ahead of the engineers, to ensure scope is defined and agreed upon before engineering starts work. So, for example, if engineering is planning on getting started on an issue in 12.2, designers will assign themselves the appropriate issues during 12.1, making sure everything is ready to go before 12.2 starts.
To make sure this happens, early planning is necessary. In the example above, for instance, we'd need to know by the end of 12.0 what will be needed for 12.2 so that we can work on it during 12.1. This takes a lot of coordination between UX and the PMs. We can (and often do) try to pick up smaller things as they come up and in cases where priorities change. But, generally, we have a set of assigned tasks for each milestone in place by the time the milestone starts so anything we take on will be in addition to those existing tasks and dependent on additional capacity.
The current workflow:
* Though Product Designers make an effort to keep an eye on all issues being worked on, PMs add the UX label to specific issues needing UX input for upcoming milestones.
* The week before the milestone starts, the Product Designers divide up issues depending on interest, expertise and capacity.
* Product Designers start work on assigned issues when the milestone starts. We make an effort to start conversations early and to have them often. We collaborate closely with PMs and engineers to make sure that the proposed designs are feasible.
* In terms of what we deliver: we will provide what's needed to move forward, which may or may not include a high-fidelity design spec. Depending on requirements, a text summary of the expected scope, a balsamiq sketch, a screengrab or a higher fidelity measure spec may be provided.
* When we feel like we've achieved a 70% level of confidence that we're aligned on the way forward, we change the label to ~'workflow::ready for development' as a sign that the issue is appropriately scoped and ready for engineering.
* We usually stay assigned to issues after they are ~'workflow::ready for development' to continue to answer questions while the development process is taking place.
* Finally, when development is complete, we conduct UX Reviews on the MRs to ensure that what's been implemented matches the spec.
## Repos we own or use
* [Prometheus Ruby Mmap Client](https://gitlab.com/gitlab-org/prometheus-client-mmap) - The ruby Prometheus instrumentation lib we built, which we used to instrument GitLab
* [GitLab CE](https://gitlab.com/gitlab-org/gitlab-ce) and [GitLab EE](https://gitlab.com/gitlab-org/gitlab-ee) - Where much of the user facing code lives
* [Omnibus](https://gitlab.com/gitlab-org/omnibus-gitlab) and [Charts](https://gitlab.com/charts/charts.gitlab.io), where a lot of the packaging related work goes on. (We ship GitLab fully instrumented along with a Prometheus instance)
## Service accounts we own or use
### Zoom sandbox account
In order to develop and test Zoom features for the [integration with GitLab](https://gitlab.com/groups/gitlab-org/-/epics/1439) we now have our own Zoom sandbox account.
#### Requesting access
To request access to this Zoom sandbox account please open [an issue](https://gitlab.com/gitlab-com/access-requests/issues/new?issuable_template=New%20Access%20Request) providing your **non-GitLab email address** (which can already be associated an existing non-GitLab Zoom account).
The following people are owners of this account and can [grant access](https://zoom.us/account/user) to other GitLabbers:
* [Andrew Newdigate](https://gitlab.com/andrewn)
* [Peter Leitzen](https://gitlab.com/splattael)
* [Allison Browne](https://gitlab.com/allison.browne)
#### Granting access
1. Log in to [Zoom](http://zoom.us/) with your non-GitLab email
1. Go to [**User Management > Users**](https://zoom.us/account/user)
1. Click on `Add User`
1. Specify email addresses
1. Choose `User Type` - most likely `Pro`
1. Click `Add` - the users receive invitations via email
1. Add the linked name to [the list in "Requesting access"](#requesting-access)
#### Documentation
For more information on how to use Zoom see theirs [guides](https://marketplace.zoom.us/docs/guides) and [API reference](https://marketplace.zoom.us/docs/api-reference/introduction).
## Async Daily Standups
The purpose of our async standups is to allow every team member to have insight into what everyone else is doing and whether anyone is blocked and could use help. This should not be an exhaustive list of all of your tasks for the day, but rather a summary of the major deliverable you are hoping to achieve. All question prompts are optional. We use the [geekbot slack plugin](https://geekbot.io/) to automate our async standup in the [#g_monitor_standup_health](https://gitlab.slack.com/messages/CNZDBHGGY) channel. Every team member should be added to the async standup by their manager.
 
source/handbook/engineering/development/ops/monitor/index.html.md.erb
+ 0
− 106
View file @ f6f8eceb
@@ -42,112 +42,6 @@ The monitoring team is responsible for:
 
This team maps to [Monitor Stage](/handbook/product/categories/#monitor-stage).
 
## How to work with Monitor
### Surfacing blockers
To surface blockers, mention your Engineering Manager in the issues, and then contact them via slack and or 1:1's. Also make sure to raise any blockers in your daily async standup using Geekbot.
The engineering managers want to make unblocking their teams their highest priority. Please don't hesitate to raise blockers
### Scheduling issues in milestones
The Product Manager is responsible for scheduling issues in a given milestone. During the backlog grooming portion of our weekly meeting, all parties will make sure that issues are scoped and well-defined enough to implement and whether they need UX involvement and/or technical investigation.
As we approach the start of the milestone, Engineering Managers are responsible for adding the ~deliverable label to communicate which issues we are committing to finish in the given milestone. Generally, the Engineering Manager will use the prioritized order of issues in the milestone to determine which issues to label as ~deliverable. The Product Manager will have follow-up conversations with the Engineering Managers if the deliverables do not meet their expectations or if there are other tradeoffs we should make.
### Scheduling bugs
When new bugs are reported, the engineering managers ensure that they have proper Priority and Severity labels. Bugs are discussed during our backlog grooming session and are scheduled according to severity, priority, and the capacity of the teams. Ideally, we should work on a few bugs each release regardless of priority or severity.
### Weekly async issue updates
Every Friday, each engineer is expected to provide a quick async issue update by commenting on their assigned issues using the following template:
```
<!---
Please be sure to update the workflow labels of your issue to one of the following (that best describes the status)"
- ~"workflow::In dev"
- ~"workflow::In review"
- ~"workflow::verification"
- ~"workflow::blocked"
-->
### Async issue update
1. Please provide a quick summary of the current status (one sentence).
1. When do you predict this feature to be ready for maintainer review?
1. Are there any opportunities to further break the issue or merge request into smaller pieces (if applicable)?
```
We do this to encourage our team to be more async in collaboration and to allow the community and other team members to know the progress of issues that we are actively working on.
### Interacting with community contributors
Community contributions are encouraged and prioritized at GitLab. Please check out the [Contribute page](/community/contribute/) on our website for guidelines on contributing to GitLab overall.
Within the Monitor stage, Product Management will assist a community member with questions regarding priority and scope. If a community member has technical questions on implementation, Engineering Managers will connect them with engineers within the team to collaborate with.
### Using spikes to inform design decisions
Engineers use spikes to conduct research, prototyping, and investigation to gain knowledge necessary to reduce the risk of a technical approach, better understand a requirement, or increase the reliability of a story estimate (paraphrased from [this overview](https://www.scaledagileframework.com/spikes/)). When we identify the need for a spike for a given issue, we will create a new issue, conduct the spike, and document the findings in the spike issue. We then link to the spike and summarize the key decisions in the original issue.
### Preparing UX designs for engineering
Product designers generally try to work one milestone ahead of the engineers, to ensure scope is defined and agreed upon before engineering starts work. So, for example, if engineering is planning on getting started on an issue in 12.2, designers will assign themselves the appropriate issues during 12.1, making sure everything is ready to go before 12.2 starts.
To make sure this happens, early planning is necessary. In the example above, for instance, we'd need to know by the end of 12.0 what will be needed for 12.2 so that we can work on it during 12.1. This takes a lot of coordination between UX and the PMs. We can (and often do) try to pick up smaller things as they come up and in cases where priorities change. But, generally, we have a set of assigned tasks for each milestone in place by the time the milestone starts so anything we take on will be in addition to those existing tasks and dependent on additional capacity.
The current workflow:
* Though Product Designers make an effort to keep an eye on all issues being worked on, PMs add the UX label to specific issues needing UX input for upcoming milestones.
* The week before the milestone starts, the Product Designers divide up issues depending on interest, expertise and capacity.
* Product Designers start work on assigned issues when the milestone starts. We make an effort to start conversations early and to have them often. We collaborate closely with PMs and engineers to make sure that the proposed designs are feasible.
* In terms of what we deliver: we will provide what's needed to move forward, which may or may not include a high-fidelity design spec. Depending on requirements, a text summary of the expected scope, a balsamiq sketch, a screengrab or a higher fidelity measure spec may be provided.
* When we feel like we've achieved a 70% level of confidence that we're aligned on the way forward, we change the label to ~'workflow::ready for development' as a sign that the issue is appropriately scoped and ready for engineering.
* We usually stay assigned to issues after they are ~'workflow::ready for development' to continue to answer questions while the development process is taking place.
* Finally, when development is complete, we conduct UX Reviews on the MRs to ensure that what's been implemented matches the spec.
## Repos we own or use
* [Prometheus Ruby Mmap Client](https://gitlab.com/gitlab-org/prometheus-client-mmap) - The ruby Prometheus instrumentation lib we built, which we used to instrument GitLab
* [GitLab CE](https://gitlab.com/gitlab-org/gitlab-ce) and [GitLab EE](https://gitlab.com/gitlab-org/gitlab-ee) - Where much of the user facing code lives
* [Omnibus](https://gitlab.com/gitlab-org/omnibus-gitlab) and [Charts](https://gitlab.com/charts/charts.gitlab.io), where a lot of the packaging related work goes on. (We ship GitLab fully instrumented along with a Prometheus instance)
## Service accounts we own or use
### Zoom sandbox account
In order to develop and test Zoom features for the [integration with GitLab](https://gitlab.com/groups/gitlab-org/-/epics/1439) we now have our own Zoom sandbox account.
#### Requesting access
To request access to this Zoom sandbox account please open [an issue](https://gitlab.com/gitlab-com/access-requests/issues/new?issuable_template=New%20Access%20Request) providing your **non-GitLab email address** (which can already be associated an existing non-GitLab Zoom account).
The following people are owners of this account and can [grant access](https://zoom.us/account/user) to other GitLabbers:
* [Andrew Newdigate](https://gitlab.com/andrewn)
* [Peter Leitzen](https://gitlab.com/splattael)
* [Allison Browne](https://gitlab.com/allison.browne)
#### Granting access
1. Log in to [Zoom](http://zoom.us/) with your non-GitLab email
1. Go to [**User Management > Users**](https://zoom.us/account/user)
1. Click on `Add User`
1. Specify email addresses
1. Choose `User Type` - most likely `Pro`
1. Click `Add` - the users receive invitations via email
1. Add the linked name to [the list in "Requesting access"](#requesting-access)
#### Documentation
For more information on how to use Zoom see theirs [guides](https://marketplace.zoom.us/docs/guides) and [API reference](https://marketplace.zoom.us/docs/api-reference/introduction).
## Async Daily Standups
We use the [geekbot slack plugin](https://geekbot.io/) to automate our async standup, following the guidelines outlined in the [Geekbot commands guide](https://geekbot.com/guides/commands/). Answers are concise and focused on top priority items. All question prompts are optional and only answered when the information should be surfaced to the team:
 
source/handbook/engineering/development/processes/Infra-Dev-Escalation/process.html.md.erb
+ 35
− 0
View file @ f6f8eceb
@@ -203,3 +203,38 @@ An [Epic of execution tracking](https://gitlab.com/groups/gitlab-com/-/epics/122
 
See the [Google sheet of schedule](https://docs.google.com/spreadsheets/d/10uI2GzqSvITdxC5djBo3RN34p8zFfxNASVnFlSh8faU/edit?usp=sharing). In the future, we could embed a summary of the upcoming
week here.
## Resources
### Coordinator Practice Guide
Below is a process that one coordinator used to fill unclaimed spots:
1. Start by finding the least filled shift (Usually this is 00:00 - 04:00 UTC) in [the on-call sheet](https://docs.google.com/spreadsheets/d/10uI2GzqSvITdxC5djBo3RN34p8zFfxNASVnFlSh8faU/edit#gid=1486652954).
1. Determine the appropriate timezone for this shift (in the case of 00:00 - 04:00 it is +9,+10,+11,+12,+13).
1. Go to the [team members list sheet](https://docs.google.com/spreadsheets/d/1Uug3QHeGYobzUbB2ajJsw7CKe7vy1xRdflO5FOuHgDw/edit#gid=1242210014) and filter the "UTC" column by the desired timezones for the shift . Now you have the list of possible people that can take this shift.
1. Go to google calendar and start to create a dummy event that is on the day and time of the unclaimed shift . NOTE you will not actually end up creating this event.
1. Add all of the people that can possibly take the shift to the event as guests.
1. Go to the "Find a Time" tab in the calendar event to see availabilities of people.
1. Find a person that is available (preferring people that have taken no shifts or few shifts based on the [total shifts counts sheet](https://docs.google.com/spreadsheets/d/10uI2GzqSvITdxC5djBo3RN34p8zFfxNASVnFlSh8faU/edit#gid=2078444703)) . Note people who are on leave or otherwise busy or in interviews, do not schedule them for the shift. It would be fine to ignored events that appeared to be normal team meetings, 1:1, coffee chat as people can always leave a meeting if there is an urgent escalation.
1. Assign them to the shift by filling their name in the the on-call sheet in Purple font color.
1. Now since there are likely many days that have this unfilled time slot then update the event date to the next day with this same unfilled time zone. Since it's the same time then the same set of people will be appropriate to take the shift which means you don't need to update the guest list.
1. Repeat all of the above for all of the unclaimed timezones remembering that you want to solve for one shift (by time range) at a time as it means you will re-use the same guest list to determine availability.
### Tips & Tricks of Troubleshooting
1. [How to Investigate a 500 error using Sentry and Kibana](https://www.youtube.com/watch?v=o02t3V3vHMs&feature=youtu.be).
1. [Walkthrough of GitLab.com's SLO Framework](https://www.youtube.com/watch?v=QULzN7QrAjY).
1. [Scalability documentation](https://gitlab.com/gitlab-org/gitlab/merge_requests/18976).
### Tools for Engineers
1. Training videos of available tools
1. [Visualization Tools Playlist](https://www.youtube.com/playlist?list=PL05JrBw4t0KrDIsPQ68htUUbvCgt9JeQj).
1. [Monitoring Tools Playlist](https://www.youtube.com/playlist?list=PL05JrBw4t0KpQMEbnXjeQUA22SZtz7J0e).
1. [How to create Kibana visualizations for checking performance](https://www.youtube.com/watch?v=5oF2rJPAZ-M&feature=youtu.be).
1. Dashboards examples, more are available via the dropdown at upper-left corner of any dashboard below
1. [Saturation Component Alert](https://dashboards.gitlab.net/d/alerts-saturation_component/alerts-saturation-component-alert?orgId=1).
1. [Service Platform Metrics](https://dashboards.gitlab.net/d/general-service/general-service-platform-metrics?orgId=1&var-type=ci-runners&from=now-6h&to=now).
1. [SLAs](https://dashboards.gitlab.net/d/general-slas/general-slas?orgId=1).
1. [Web Overview](https://dashboards.gitlab.net/d/web-main/web-overview?orgId=1).
\ No newline at end of file
source/handbook/engineering/infrastructure/environments/index.html.md
+ 9
− 4
View file @ f6f8eceb
@@ -47,7 +47,12 @@ APIs are enabled for each GCP project via Infrastructure as Code (terraform).
| --- | --- | --- | --- | --- | --- |
| .org | [dev.gitlab.org](https://dev.gitlab.org) | Tools for Gitlab.com | Nightly | Real Work | Production and build team |
 
Currently there are two main uses for the .org environment, Builds and repos that are needed in case gitlab.com is offline. This is a critical piece of infrastructure that is always growing in size due to build artifacts. There are discussions to make a new build server where nightly CE/EE builds can be deployed or to move the infra repos to a new host that would be an separate (not gitlab.com) EE instance. Although the environment has dev in its domain name don't refer to it as dev since that could be confused with a local development environment.
Currently there are two main uses for the .org environment:
- Builds.
- Repos that are needed in case GitLab.com is offline.
This is a critical piece of infrastructure that is always growing in size due to build artifacts. There are discussions to make a new build server where nightly CE/EE builds can be deployed or to move the infra repos to a new host that would be an separate (not gitlab.com) EE instance. Although the environment has dev in its domain name don't refer to it as dev since that could be confused with a local development environment.
 
### Review Apps
 
@@ -96,7 +101,7 @@ At this time it includes:
Production will be full scale and size with the ability to have a canary deploy. Production has limited access.
It consists of two stages:
 
* The canary stage is a subset of infrastructure that reaches a limited number of members of the community. We deploy to this stage first. For more information see [canary testing](/handbook/engineering/#canary-testing).
* The canary stage is a subset of infrastructure that reaches a limited number of members of the community. We deploy to this stage first. For more information see [canary testing](/handbook/engineering/#canary-testing).
* The main stage serves the remaining traffic for the wider GitLab community.
 
### Staging
@@ -107,7 +112,7 @@ It consists of two stages:
 
Staging has the same topology as Production and includes the same components, since they share the same [terraform configuration](https://gitlab.com/gitlab-com/gitlab-com-infrastructure/tree/master/shared/gstg-gprd).
 
Staging deployments precede production deployments as described in [releases](/handbook/engineering/releases), but is deployed a lot more frequently (at least every few hours, given the build is green). This would be a static environment with an pseudonymized production database. The DB is a snapshot of the production DB (updated only often enough to keep migration times to a minimum).
Staging deployments precede production deployments as described in [releases](/handbook/engineering/releases), but Staging is deployed a lot more frequently (at least every few hours, given the build is green). This would be a static environment with an pseudonymized production database. The DB is a snapshot of the production DB (updated only often enough to keep migration times to a minimum).
 
If you need an account to test QA issues assigned to you on Staging, you may already have an account as Production accounts are brought across to Staging. Otherwise, if you require an account to be created, create an issue in [the access-request project](https://gitlab.com/gitlab-com/access-requests/issues/new?issuable_template=New%20Access%20Request) and assign to your manager for review. Requests for access to database and server environments require the approval of your manager as well as that of one of the Infrastructure managers. The same [access-request tracker](https://gitlab.com/gitlab-com/access-requests/issues/new?issuable_template=New%20Access%20Request) should be used to request this type of access.
 
@@ -146,4 +151,4 @@ These are environments that are run on-premises by the end-user. We have no infl
 
## Nodes
 
If you work at GitLab also see the [list of nodes managed by Chef](https://ops.gitlab.net/gitlab-cookbooks/chef-repo/tree/master/nodes) to get an idea.
If you work at GitLab, also see the [list of nodes managed by Chef](https://ops.gitlab.net/gitlab-cookbooks/chef-repo/tree/master/nodes) to get an idea.
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment