Define critical patch release process characteristics
Context
During the last quarters, Delivery has worked towards a fast and better patch release process, as a consequence patch releases have been repurposed to include bug and security fixes, and recurrently scheduled every 2 weeks to account for GitLab SLO/SLAs (see &1193 for details).
Before this modality, ad-hoc patches, called critical security releases, were triggered on demand when a high vulnerability was discovered. With recurrent patch releases meeting bug and vulnerabilities SLAs, the objective of a critical process is murky:
- How is "critical" defined? Critical is tied to security vulnerabilities, with patch relates including bug fixes, should a patch release be deemed critical if it contains an S1 bug fix?
- When the critical security process should be used? If a high-severity vulnerability (S1) is discovered, the remediation time of 30 days for self-managed allows the fix to be included in the next planned patch release.
- What internal release process should be used? Performing a critical security release involves a manual and different process from the default patch release process.
Proposal - Define critical patch release process characteristics
The purpose of this issue is to define:
- What accounts for "critical"? Does critical mean out-of-bound patch release (unplanned)? or does it mean that a patch release has a high-severity vulnerability or bug fixes (S1) included?
- What internal process should be used for critical patch releases?
- What communication is required? Blog Post + Slack Notifications
- What communication is required for in-house instances (Dedicated)?
To do
-
Deprecate internal process in favor of automated one #19904 -
Collaborate with AppSec and Product to answer the above questions -
Review if during upcoming quarters any high-severity issue requires a faster process than a planned release -
Adjust documentation
Edited by Mayra Cabrera