Evaluate the role of the release instance (release.gitlab.net) in testing upgrade paths

Context

In the handbook, the release instance (release.gitlab.net) is mentioned with the purpose of "Deploying self-managed releases", where we deploy Final monthly, patch and security releases. So, we test upgrade paths between self-managed releases on the release instance.

At the same time, the Developer Experience team supports different update scenarios QA, which seem to be similar.

Problem Statements

The release instance (release.gitlab.net) is a GitLab Omnibus setup running on a single virtual machine (VM). Maintaining it requires additional efforts from the Delivery group to upgrade the host's OS, security review, release tasks to deploy and validate, etc. For example, due to https://gitlab.com/gitlab-com/gl-infra/delivery/-/issues/21020, there is a need to rebuild the release instance.

If the tooling of the Developer Experience team already supports the same purpose of the release instance, we may consider using the existing tools instead of keep maintaining the release instance, to improve the efficiency of our work while maintaining the result for the customers.

Result

• The release instance is used to test the update paths between released versions (i.e. from the previous released version to the upcoming one)
• The update scenarios QA can cover all update paths
• We should plan and implement the update scenarios QA in our release pipelines (monthly + patch) to replace the release instance