Self-Managed Platform team
Self-Managed Platform team in Test Platform sub-department
Common Links
Engineers in this team support the product sections supported by the Core Platform, SaaS Platforms along with maintaining the self managed platform tools.
Team members
Engineering Manager: Kassandra Svoboda
OKRs
Every quarter, the team commits to Objectives and Key Results (OKRs). The below shows current quarter OKRs and is updated regularly as the quarter progresses.
Here is an Overview of our current Self-Managed Platform team OKR.
Projects
Working with us
There are occasions where the expertise of the Reference Architecture or Self-Managed Platform team may be needed in support of a customer issue.
For any requests relating to customer environments, either proposed or existing, they must be raised in the Reference Architectures project with the appropriate template. Requests should be opened two or more business days before action is needed to ensure the team has time to prepare and we kindly ask for this process to be followed for tracking and capacity reasons. Any requests made outside of this process such as direct asks to join customer calls or projects will be rejected and should instead be directed to Support or Professional Services accordingly.
For issues specifically with the GitLab Environment Toolkit or GitLab Performance Tool issues can be raised in each respective project.
For individual questions please reach out to the team via our slack channels.
Slack Channels
How we work
Meetings and Scheduled Calls
Our preference is to work asynchronously, within our projects issues trackers.
The team does have a set of regular synchronous calls:
- Self-Managed Environment Triage
- GitLab Environment ToolKit Bi-Weekly Sync
- 1-1s between the Individual Contributors and Engineering Manager
Stand-up twice per week on Tuesday and Thursday via our teams slack channel
Project Management
Issue Boards
We track our work on the following issue boards:
Capacity Planning
We use a simple issue weighting system for capacity planning, ensuring a
manageable amount of work for each milestone. We consider both the team’s
throughput and each engineer’s upcoming availability from Time Off by Deel.
The weights are intended to be used in aggregate, and what takes one person a
certain amount of time may be different for another, depending on their level of
knowledge of the issue. We should strive to be accurate, but understand that
they are estimates. We will change the weight if it is not accurate or if the issue
becomes more difficult than originally expected, leave a comment indicating why the
weight was changed, and tag the EM and any assigned DRIs so we can better understand the scope
and continue to improve.
Weights
To weigh an issue, consider the following important factors:
- Volume of work: expected size of the change to the code base or validation testing required.
- Amount of investigation or research expected.
- Complexity:
- Problem understanding: how well the problem is understood.
- Problem-solving difficulty: the level of difficulty we expect to encounter.
The following weights are available based on the Fibonacci Series with 8 being the highest assignable number. The definitions are as below:
| Weight |
Description |
Examples |
| 1 - Trivial |
Simple and quick changes |
Documentation fixes or smaller additions. |
| 2 - Small |
Straight forward changes, no underlying dependencies needed with little investigation or research required. |
Smaller Ansible additions or changes, e.g. within one role. |
| 3 - Medium |
Well understood changes with a few dependencies that should only require a reasonable amount of investigation or research. |
Large Ansible changes, e.g. affecting multiple roles.
Small Terraform additions or changes, such as an additional setting for a Cloud Service. |
| 5 - Large |
A larger task that will require a notable amount investigation and research.
All changes relating to security. |
Large Terraform additions or changes such as a new Cloud Service or changes affecting multiple components. |
| 8 - X-large |
A very large task that will require a significant amount of investigation and research. Pushing initiative level. |
Large GitLab changes such as new component that will require joint Reference Architecture, GET and GPT work |
Anything that would be assigned a weight of 8 or larger should be broken down.
Status Updates
- By 20:00 UTC / 03:00 PM ET on Fridays DRIs of OKRs to provide a status update in the comment section of the OKR
- Format for weekly update:
- Date of Update (YYYY-MM-DD)
- Brief update (~sentence or couple bullets) for each of these four bullets:
- Status update - Progress has been updated to X %.
- What was done ✅ - Unblocked blockers, any other progress acheived
- Next steps 👷
- Blockers :octagonal_sign: - Issues or unexpected work that blocked/affected progress. For example, customer escalations/on-call DRI
- ASYNC Standup on Tuesdays and Thursdays - Reply to GeekBot questionaire on Slack.
Overall we follow the same process as defined in our Test Platform handbook across all groups in Core Platform and SaaS Platform
except for a few exceptions curated to fit the needs of specific groups.
Overview The goal of this page is to document existing Quality Engineering activities in Distribution group.
Dashboards QE Distribution dashboard - Dashboard to track Quality Engineering work items Distribution Issues - Dashboard to visualize metrics important for Bug Prioritization Bug Prioritization metrics - Bugs metrics required for Bug Prioritization (ensure to filter by Distribution group) Quality work Quality work is being tracked in epic#9057. The epic lists large initiatives that need to be worked on to better support quality in Distribution group.
