Proposal: Establish an RCA process for unplanned patch releases
Context
&1193 (closed) introduced a single release for bug and security fixes: patch releases. These releases are SLO-driven to account for vulnerabilities and bug fixes remediation SLOs. These SLOs were established for a reason and are the GitLab standard approach and guideline for releases.
Even though Releases adhere to the SLOs, there might be scenarios that require scheduling patch releases outside of this cadence. Unplanned releases are not free: They represent a bad release experience because the SLO is not respected, which causes this metric to lose this value and signal that it doesn't fit the release requirements.
Proposal: Establish an RCA process for unplanned releases
Because patch releases follow a regular cadence based on SLO, unplanned releases should always be the result of an incident, as such, they should be treated as one. A root cause analysis (RCA) process along with a Feature Change Lock (FCL) should be a requirement when unplanned releases are required.
Pros:
- This creates a soft mental barrier for engineers/product, e.g. Do I really need to raise an incident for this?
- Allow us to track offenders and put in place corrective actions that EM in the respective stage team can manage.