Delivery::Releases FY25 Q2 OKRs ideas and discussion
Context
We are few weeks away from FY25 Q2 and it is time to start planning for OKRs. Let's use this issue to suggest possible ideas and discuss the best combination of ideas and scope to set us up for Q2.
FY25 Q1 State
This is the first quarter as the teamDelivery-Releases team. We made good progress on several axes of the Security Patch Releases:
- Transforming patch and security releases to be SLO-driven and allowing us to build predictability for the development team and our customers:]
- Release Environments to increase confidence of releasing a quality product, even for older GitLab versions
- Releases Dashboard to build the visibility for the development teams for the various release windows so that they have better confidence on their development schedule
the previous steps we took that brought us here are:
- Automating and combining bug fixes and security fixes into patch releases
- Reduce Security release preparation to less than 24hrs
- The work on Creating Release Environments, for testing new releases in the supported maintenance policy restarted, and it has made significant progress.
- We are currently in the final weeks of the Pilot of two scheduled security releases per month in preparation for planned releases
The teamDelivery-Deployments team made significant progress in Developing support for Ring 0 deployments in release-tools and starting the work around tracking environments' ability to receive a deployment.
FY25 Q1 - What's next?
During the work done FY25 Q1, we identified several new work items that would fit the next iterations of these projects. Some of these items identified could benefit from some of the learnings we will get from the actual use of what we built during Q2.
In addition, we developed a new Delivery Group direction that is about to be merged (thanks, @swiskow, for driving the group on this!) that would give us aspirational goals we will iterate towards. Please give a read to the MR to get some inspiration.
We have plenty of areas for automation. The first two that come to mind are Monthly and Patch Releases. This should reduce the overall Release Management workload and allow us to focus more on project work in the longer term.
In the last 7/8 months, we also faced some challenges in having to coordinate Security releases to mitigate internal environments. This is something that will happen again in the future, also in light of Cells. Taking an initial step towards solving this problem is also food for thought.
Please let's share our OKR ideas for FY25 Q2.
We also have a Roadmap epic for Delivery:Releases, please take this into consideration and start contributing to it
Proposed FY25 Q2 OKRs
Objective: Improve the predictability of releases through automation
- KR: 100% of Monthly Release Management steps are automated
- KR: 50% of Patch Release Management steps are automated. (This KR also includes work to refine the current RE solution, and I am expecting that 100% of Patch Releases be automatically validated by Release Environments by the end of the quarter and integrated into the Patch Release Automation we are going to work on)
Objective: Lay foundation for improved security posture on Dedicated and Cells
- KR: Deliver the blueprint that defines Internal Releases
Exact wording of the OKRs might change.
Timeline
- Due date for idea submission is set to
2024-04-17
- Due date of this issue - Creation of first draft of OKRs on the
2024-04-18
- Formalize our final draft for the OKRs by
2024-04-22
- Consolidate OKRs with Department OKRs by
2024-04-25
Those dates are also present on the SaaS Platforms Leadership Calendar, consider adding it to your calendars
@gitlab-org/delivery/releases for your attention. @gitlab-org/delivery to increase group visibility.