The Ops Sub-department is composed of development teams working on Verify, Package, Release, Configure, and Monitor features of GitLab DevOps Platform.
The following teams comprise the Ops sub-department:
Product direction can be found on the Ops Section Product Direction handbook page.
(Sisense↗) We also track our backlog of issues, including past due security and infradev issues, and total open 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.
GitLab encourages transparency by default, and when meetings are recorded, they can be automatically synced to Google Drive as highlighted in the section about how we conduct video calls at GitLab. To summarize:
youremail-Meeting Title, even if alternate hosts start the recording.
Starting in 2023 in FY24-Q1, a fresh new format for this showcase will include the recording and sharing of videos that team members have created. Once a video has been created, an async discussion issue should be created using this template and listed under the relevant quarterly epic. Based on the amount of questions being discussed in the issue, an AMA may be set up to discuss further in a group setting. Like before, these videos are intended to be opportunities for engineers to show off the things they've been working on.
Beginning in March 2023 all Ops teams are required to provide at least one showcase video and async discussion issue per month. We require participation in this process because it helps reinforce our values of Results, Transparency, and Iteration. In addition, these showcases are valuable in helping team members across the company better understand the progress and obstacles across the many product areas Ops team members are focused on. They are also fun to watch. These videos will be reviewed monthly by the Director of Engineering and other leaders in the group. The team's Engineering Manager is the DRI for submitting the showcase, though in many cases the demo may be delegated to another member of the team.
Team members are encouraged to use these videos to transparently showcase the current state of their projects. It is not encouraged to spend significant time prepping for these demos or only showcase finished, polished functionality; showing functionality in an incomplete state is encouraged. Videos may be specifically recorded for this purpose or be excerpts from team meetings, etc. Some suggested ideas to consider could be related to error budget improvements, performance improvements to current features, refactoring to codebase for future maintainability, etc.
|2022||December||No showcases||No showcases|
|2022||November||No showcases||No showcases|
|2022||October||Split GitLab Monolith into components||No showcases||TaskScaler 101|
|2022||September||Import packages with a CI pipeline||No showcases|
|2022||August||No showcases||Async video ->||Leader election in GitLab Agent for Kubernetes|
|2022||July||Video||No showcases||MR Coverage Report & CI Workflows|
|2022||January||Video||No showcases||Jobs UI Refactor|
Planning processes followed by teams in the Sub-department:
Our prioritization framework describes a number of Forced Priority labels that present a high risk to our customers and our business. As such, it's critical that we complete this work within the appropriate SLO/SLAs where possible. An example of this are security issues, here's a dashboard for past due and soon to be due security issues: https://app.periscopedata.com/app/gitlab/913607/Past-Due-Security-Issues-Development
With this in mind, here's a process that groups are encouraged to use and iterate on in the event that they don't have an existing approach or are falling behind on SLA/SLOs.
To be clear, this is not a required process, if your group's approach is working, please continue with that! Ownership of scheduling forced priority work falls on our whole team, not a particular person.
Ops Managers, Sr. Managers, and Directors meet in the last month of each quarter to:
We have limited capacity in the recruiting team so hiring managers are experimenting with the Ops Hiring process. We also hold a weekly hiring manager sync meeting (see Meetings section).
|5 weeks before||OKR kickoff. Quick sync to review schedule and expectations. Director Ops and direct reports.|
|4 weeks before||Next Quarter OKR Planning - Initial Review Session - Director, SEMs, EMs - Review CEO, CTO, CProjO and VP Development OKR drafts|
|3 weeks before||Next Quarter OKR Planning - 50 minute Director/SEM OKR review meeting. Ops Directors+, Sr. EMs, Group PMs propose OKRs for their groups in Working Drafts (existing document (internal))|
|2 weeks before||Next Quarter OKR Planning - 50 minute SEM/EM meeting for Verify and CD compartment. EMs propose OKRs for their groups via issues linked from review meeting doc.|
|1 week before||OKRs are moved into Ally. Directors, SEMs, EMs document how to achieve following guidance in https://about.gitlab.com/company/okrs/#documenting-how-to-achieve|
|1 week before||OKRs and how to achieve docs are shared by DRIs in #doe-ops and other appropriate slack channels.|
|1st week of quarter||Ops Sub-Dept OKR AMA. 25 minute kickoff meeting to discuss OKRs and answer questions.|
from x to y).
**Good** - Things that went well... **Bad** - Things that didn't go so well... **Try** - What might you do differently next time?
We have a policy in Ops to keep status updates out of meetings. Instead of reporting on status in meetings Directors, Senior Engineering Managers, Engineering Managers and Principal Engineers provide regular async updates.
The content of these updates varies by individual and role:
~OpsSection::AsyncUpdate. (The label
~OpsSection::Weekly-Updatecan also be used for backwards compatibility reasons.)
~OpsSection::Weekly-Updatelabel are summarized in weekly issues in the Ops Status Updates project.
We are piloting a process to make coordinating with the Support team on customer escalations more efficient.
See How to Use GitLab.com to Formally Request Help from the GitLab Ops Development Team for process details.
If you encounter an Ops-related customer escalation, that seems to have a high
and would benefit from additional visibility, please post a link with a short description in
#doe-ops Slack channel.