Skip to content

Investigation: What are the backports required for an internal release?

Context

Delivery team is introducing an internal release process to remediate GitLab Dedicated instances in light of a high-severity security issue. Commonly GitLab Dedicated runs the patch set version N-1 out of the three supported minor versions N, N-1 and N-2, but the actual version will depend on the release schedule and the weekly maintenance. For example:

  • The current version is 17.4 with the active version 17.5 (i.e. 17.5 is being working on to release)
  • Because Dedicated uses N-1, all instances are running 17.3.5 (last patch version of 17.3)
  • October 17th (Thursday): GitLab 17.5 is released
  • October 21st (Monday): GitLab Dedicated starts scheduled maintenance to upgrade instances to 17.4.2 (last patch version of 17.4)
  • October 27th (Sunday): Upgrading cycle complete. All GitLab customers should be running on 17.4.2

If any high-severity issue is discovered on the scheduled maintenance week, some Dedicated customers will be running on 17.3, so an internal release for 17.3 will also be required

Proposal: Analyze what are the backports required for an internal release

From the above scenario, looks like three options are possible:

  1. Option A: Prepare internal releases for N-1 and N-2 versions. For example, if 17.4 is the current stable release, internal releases will be prepared for 17.3 and 17.2
  2. Option B: Prepare internal releases for N-1 version, which is what Dedicated is running. For example, if 17.4 is the current stable release, internal release will be prepared for 17.3
  3. Option C: Prepare internal releases for all versions within the policy. For example, if the maintenance policy supports backporting security fixes 17.4, 17.3 and 17.2, internal releases will be prepared for those versions.

Analysis result 👨‍🔬

Please check #20621 (comment 2173844472)

Decision 🏁

Considering N, N-1 and N-2 are the three minor versions within our maintenance policy, Internal release is done for N-1 and N-2.

Example: On time date 2024-10-28, 17.6 is the active version, the three minor versions within our maintenance policy are 17.5, 17.4 and 17.3. Thus, in case internal releases is needed today, they would be done for 17.4 (N-1) and 17.3 (N-2).

External requirements

  • Update path from a N-1 internal release version to a N internal release version works (e.g. from 17.3.5-internal0 to 17.4.2-internal0)
  • When needing to patch due to a critical security vulnerability, a Dedicated instance is always updated to the internal release on the same minor version the instance is running on, for example if the instance is running 17.3.x, it is going to update to 17.3.x-internal<internal-version-number>.
  • The next patch release must include the fix(es) in the previous internal releases to avoid regression.
  • Why N is not supported at the moment: N is required in case an internal release happens after a patch release and before the next monthly release. However, if the internal release happens between a patch release and a monthly release, it falls into the case of Unplanned critical patch release. The first iteration of internal release (i.e. Bridge the patch release process with GitLab SaaS single tenant instance remediation) still cannot solve the blocking nature of GitLab releases. It will be solved in another epic following the Proposed plan of action in the blueprint. In summary, the only use case of N is not supported by Internal releases at the moment, so N is not needed.

TODOs

  • Analyze cons and pros of each option
  • Decide on what option should we use on the first iteration.
Edited by Dat Tang