Fixed windows for 17.0 breaking changes rollout
Executive Summary
We will introduce the following breaking change windows in the 17.0
milestone:
-
2024-04-22 09:00UTC
to2024-04-24 22:00UTC
-
2024-04-29 09:00UTC
to2024-05-01 22:00UTC
-
2024-05-06 09:00UTC
to2024-05-08 22:00UTC
Breaking changes should only be enabled during these periods. This means that where breaking changes are behind feature flags, the changes (feature flag) should only be switched during one of these periods to ensure customers workflows are not impacted outside of these communicated periods.
We are working on a blog post, newsletter and series of in-app messaging communications to ensure that customers are aware of these windows in advance of the 17.0
milestone.
For any questions, please add a comment to this issue.
Context
We continuously roll out changes to GitLab.com, many times a day. We also package the changes we make to GitLab.com into numbered versioned packages for our self managed and dedicated customers. The numbered versions come out on a predictable schedule (3rd Thursday of the month), giving customers the ability to predict and plan for breaking change. However changes roll out to gitlab.com regularly as part of the continuous delivery process and are not as predictable for customers. This includes breaking changes.
Problem
GitLab.com customers get delivered breaking changes on a schedule that is not known up front to them. This is not a satisfactory experience and can cause customer workflows to be broken suddenly.
Proposal
- We should agree on one or two windows where we will introduce breaking changes and publicise (in the newsletter) those windows to customers.
- The breaking changes should be introduced by using the feature flag to deliver the breaking change - meaning that the change can easily be reversed if the flag causes an incident or large customer impact
- In disaster circumstances, Delivery can delay the release 1 day to allow feature flags to be defaulted to
on
so they can be included in the package for features that fail to remove the feature flag in time for the major release. This should be avoided unless all other avenues have been exhausted.
Execution Plan
-
Working group to agree on two fixed windows for product teams to aim for -
Product DRI @mflouton
to socialise windows with PLT and confirm this is deliverable by product teams -
Newsletter item to be drafted confirming windows with gitlab.com customers -
In-App messaging banner to be displayed during the two windows
Open Questions
- How many breaking change windows should we have?
- What do we do for groups and changes that miss the windows?