diff options
| author | GitLab Bot <gitlab-bot@gitlab.com> | 2021-07-15 21:09:37 +0300 |
|---|---|---|
| committer | GitLab Bot <gitlab-bot@gitlab.com> | 2021-07-15 21:09:37 +0300 |
| commit | d811b6d8f61b45cd12f94251abff9102b8cefc19 (patch) | |
| tree | 064f5bdcf19c1480959ff02b752ab8fafa46c0fc /doc/development/multi_version_compatibility.md | |
| parent | 1581767ea15fcfa63919d39c0d3579da0a4de96e (diff) | |
Add latest changes from gitlab-org/gitlab@master
Diffstat (limited to 'doc/development/multi_version_compatibility.md')
| -rw-r--r-- | doc/development/multi_version_compatibility.md | 24 |
1 files changed, 18 insertions, 6 deletions
diff --git a/doc/development/multi_version_compatibility.md b/doc/development/multi_version_compatibility.md index 8e49afda579..a12c01c734a 100644 --- a/doc/development/multi_version_compatibility.md +++ b/doc/development/multi_version_compatibility.md @@ -115,12 +115,24 @@ For major or minor version updates of Rails or Puma: ### Feature flags -One way to handle this is to use a feature flag that is disabled by -default. The feature flag can be enabled when the deployment is in a -consistent state. However, this method of synchronization **does not -guarantee** that customers with on-premise instances can [update with -zero downtime](https://docs.gitlab.com/omnibus/update/#zero-downtime-updates) -because point releases bundle many changes together. +[Feature flags](feature_flags/index.md) are a tool, not a strategy, for handling backward compatibility problems. + +For example, it is safe to add a new feature with frontend and API changes, if both +frontend and API changes are disabled by default. This can be done with multiple +merge requests, merged in any order. After all the changes are deployed to +GitLab.com, the feature can be enabled in ChatOps and validated on GitLab.com. + +**However, it is not necessarily safe to enable the feature by default.** If the +feature flag is removed, or the default is flipped to enabled, in the same release +where the code was merged, then customers performing [zero-downtime updates](https://docs.gitlab.com/omnibus/update/#zero-downtime-updates) +will end up running the new frontend code against the previous release's API. + +If you're not sure whether it's safe to enable all the changes at once, then one +option is to enable the API in the **current** release and enable the frontend +change in the **next** release. This is an example of the [Expand and contract pattern](#expand-and-contract-pattern). + +Or you may be able to avoid delaying by a release by modifying the frontend to +[degrade gracefully](#graceful-degradation) against the previous release's API. ### Graceful degradation |