From 07f52e4e98af6e26d69726026eb8e7cbe847fd17 Mon Sep 17 00:00:00 2001 From: Lysanne Pinto <lpinto@gitlab.com> Date: Fri, 4 Oct 2024 19:27:52 +0000 Subject: [PATCH] Split maintenance content from GitLab Dedicated subscriptions page --- .../dedicated/create_instance.md | 2 +- doc/subscriptions/gitlab_dedicated/index.md | 43 ------------ .../gitlab_dedicated/maintenance.md | 65 +++++++++++++++++++ 3 files changed, 66 insertions(+), 44 deletions(-) create mode 100644 doc/subscriptions/gitlab_dedicated/maintenance.md diff --git a/doc/administration/dedicated/create_instance.md b/doc/administration/dedicated/create_instance.md index bb1d9214c6eda..06ec304ec0bfd 100644 --- a/doc/administration/dedicated/create_instance.md +++ b/doc/administration/dedicated/create_instance.md @@ -229,7 +229,7 @@ Consider the following notes: #### GitLab release rollout schedule -GitLab Dedicated tenant instances are [upgraded](../../subscriptions/gitlab_dedicated/index.md#upgrades-and-patches) to the minor GitLab release within [the pre-selected window](#maintenance-window) using the schedule described below. +GitLab Dedicated tenant instances are [upgraded](../../subscriptions/gitlab_dedicated/maintenance.md#upgrades-and-patches) to the minor GitLab release within [the pre-selected window](#maintenance-window) using the schedule described below. Where **T** is the date of a [minor GitLab release](../../policy/maintenance.md) `N`. GitLab Dedicated instances are upgraded to the `N-1` release as follows: diff --git a/doc/subscriptions/gitlab_dedicated/index.md b/doc/subscriptions/gitlab_dedicated/index.md index 8fec3c88bc1eb..d9b77db4adad8 100644 --- a/doc/subscriptions/gitlab_dedicated/index.md +++ b/doc/subscriptions/gitlab_dedicated/index.md @@ -22,29 +22,6 @@ It's the offering of choice for enterprises and organizations in highly regulate GitLab Dedicated uses the [advanced search functionality](../../integration/advanced_search/elasticsearch.md). -#### Zero-downtime upgrades - -Deployments for GitLab Dedicated follow the process for [zero-downtime upgrades](../../update/zero_downtime.md) to ensure [backward compatibility](../../development/multi_version_compatibility.md) of the application during an upgrade. When no infrastructure changes or maintenance tasks require downtime, using the instance during an upgrade is possible and safe. - -During a GitLab version update, static assets may change and are only available in one of the two versions. To mitigate this situation, GitLab Dedicated adopts three techniques: - -1. Each static asset has a unique name that changes when its content changes. -1. The browser caches each static asset. -1. Each request from the same browser is routed to the same server temporarily. - -These techniques together give a strong assurance about asset availability: - -- During an upgrade, a user routed to a server running the new version will receive assets from the same server, completely removing the risk of receiving a broken page. -- If routed to the old version, a regular user will have assets cached in their browser. -- If not cached, they will receive the requested page and assets from the same server. -- If the specific server is upgraded during the requests, they may still be routed to another server running the same version. -- If the new server is running the upgraded version, and the requested asset changed, then the page may show some user interface glitches. - -To notice the effect of an upgrade, a new user of the system should connect for the first time during a version upgrade and get routed to an old version of the application immediately before its upgrade. The subsequent asset requests should end up in a server running the new version of GitLab, and the requested assets must have changed during this specific version upgrade. If all of this happens, a page refresh is enough to restore it. - -NOTE: -Adopting a caching proxy in the customer network will further reduce this risk. - ### Security #### Authentication and authorization @@ -124,26 +101,6 @@ To add a custom hostname after your instance is created, submit a [support ticke NOTE: Custom hostnames for GitLab Pages are not supported. If you use GitLab Pages, the URL to access the Pages site for your GitLab Dedicated instance would be `tenant_name.gitlab-dedicated.site`. -### Maintenance - -GitLab leverages [weekly maintenance windows](../../administration/dedicated/create_instance.md#maintenance-window) to keep your instance up to date, fix security issues, and ensure the overall reliability and performance of your environment. - -#### Upgrades and patches - -Your GitLab Dedicated instance receives regular upgrades during your preferred maintenance window. These upgrades include the latest patch release for the minor version that is one version behind the current GitLab release. For example, if the latest GitLab version is 16.8, your GitLab Dedicated instance runs on 16.7. -For more information, see the [GitLab release and maintenance policy](../../policy/maintenance.md). - -Monthly updates include: - -- One minor release -- Two patch releases - -To view details about your instance, including upcoming scheduled maintenance and the current GitLab version, sign in to Switchboard. - -#### Emergency maintenance - -GitLab performs [emergency maintenance](../../administration/dedicated/create_instance.md#emergency-maintenance) to address high-severity issues that affect your instance's security, availability, or reliability. When critical patch releases are available, GitLab Dedicated instances are upgraded as soon as possible using emergency maintenance procedures. - ### Application GitLab Dedicated comes with the self-managed [Ultimate feature set](https://about.gitlab.com/pricing/feature-comparison/) with the exception of the [unsupported features](#features-that-are-not-available) listed below. diff --git a/doc/subscriptions/gitlab_dedicated/maintenance.md b/doc/subscriptions/gitlab_dedicated/maintenance.md new file mode 100644 index 0000000000000..0e89f6a285acc --- /dev/null +++ b/doc/subscriptions/gitlab_dedicated/maintenance.md @@ -0,0 +1,65 @@ +--- +stage: SaaS Platforms +group: GitLab Dedicated +description: Maintenance procedures, including regular upgrades, zero-downtime deployments, and emergency maintenance protocols. +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments +--- + +# Maintenance + +DETAILS: +**Tier:** Ultimate +**Offering:** GitLab Dedicated + +GitLab Dedicated instances receive regular maintenance to ensure security, reliability, and optimal performance. + +## Maintenance windows + +GitLab leverages [weekly maintenance windows](../../administration/dedicated/create_instance.md#maintenance-window) to keep your instance up to date, fix security issues, and ensure the overall reliability and performance of your environment. + +## Upgrades and patches + +Your instance receives regular upgrades during your preferred maintenance window. These upgrades include the latest patch release for the minor version that is one version behind the current GitLab release. For example, if the latest GitLab version is 16.8, your GitLab Dedicated instance runs on 16.7. + +Monthly updates include: + +- One minor release +- Two patch releases + +To view details about your instance, including upcoming scheduled maintenance and the current GitLab version, sign in to Switchboard. + +For more information, see the [GitLab release and maintenance policy](../../policy/maintenance.md). + +### Zero-downtime upgrades + +Deployments follow the process for [zero-downtime upgrades](../../update/zero_downtime.md) to ensure [backward compatibility](../../development/multi_version_compatibility.md) during an upgrade. When no infrastructure changes or maintenance tasks require downtime, using the instance during an upgrade is possible and safe. + +During a GitLab version update, static assets may change and are only available in one of the two versions. To mitigate this situation, three techniques are adopted: + +1. Each static asset has a unique name that changes when its content changes. +1. The browser caches each static asset. +1. Each request from the same browser is routed to the same server temporarily. + +These techniques together give a strong assurance about asset availability: + +- During an upgrade, a user routed to a server running the new version receives assets from the same server, eliminating the risk of receiving a broken page. +- If routed to the old version, a regular user has assets cached in their browser. +- If not cached, they receive the requested page and assets from the same server. +- If the specific server is upgraded during the requests, they may still be routed to another server running the same version. +- If the new server is running the upgraded version, and the requested asset changed, then the page may show some user interface glitches. + +The effects of an upgrade are usually unnoticeable. However, in rare cases, a new user might experience temporary interface inconsistencies: + +- The user connects for the first time during an upgrade. +- They are initially routed to a server running the old version. +- Their subsequent asset requests are directed to a server with the new version. +- The requested assets have changed in the new version. + +If this unlikely sequence occurs, refreshing the page resolves any visual inconsistencies. + +NOTE: +Implementing a caching proxy in your network further reduces this risk. + +## Emergency maintenance + +[Emergency maintenance](../../administration/dedicated/create_instance.md#emergency-maintenance) addresses high-severity issues that affect your instance's security, availability, or reliability. When critical patch releases are available, GitLab Dedicated instances are upgraded as soon as possible using emergency maintenance procedures. -- GitLab