Add Feature to Migrate Existing Service Template Instance Integration

Background

As discussed in the Service Template -> Instance-Level Integration migration path (#204770 (closed)), we want to allow users to migrate active Service Templates to Instance-Level integrations.

When we launch Instance-Level Integration, we may not need anything in the UI to accomplish this and can likely provide some console commands that could make this transition.

However, if we choose to provide it, the ability to make this transition in the Service Template UI would make this transition much more user friendly.

Behind the scenes, this migration once triggered, would perform the following steps:

• Change the Service Template Service record to an Instance Service record. Ex: { template: true, instance: nil } becomes { instance: true, template: nil }
• Find any project Service records created with the Service Template and delete them. It could be tricky to identify these records since they could have been modified after the project was created. We may just want to look for any records with settings fields matching those of the Service Template
• Once these Service records are removed, the associated projects should then inherit the settings of the Instance-Level Integration config.

Problem to solve

Once we add the ability for Admins to create Instance-level integrations, if they are currently using Service Templates, the best practice for them would be to migrate to this new functionality. Because of the way that Service Templates work, this migration could mean that they have to go manually update thousands of projects on a per-project basis. Particularly because this is one-off work, and they will not need to do it again once it's been completed, it's a particularly painful workflow that doesn't benefit from them creating automation.

Additionally, a manual migration is ripe for error, since they could miss projects that are using the template, they could fail to delete the old template and continue to create problems in the future, and they could fail to notice specific projects that are overriding settings and mistakenly pave them.

User Stories

• As a user of Service Templates, I want to know how many projects are currently using this template so that I can understand the impact of my change
• As a user of Service Templates, I want the ability to create an integration based on this template so that I can quickly roll out this change
• As a user of Service Templates, I want the ability to overwrite the existing service template data on existing projects so that I don't have to individually change each one

Proposal

Create a new feature in the Service Template configuration page that allows a user to convert a Service Template to an integration. This feature should copy the existing values in to a new integration, remove the old values that will be inheriting this new integration (as long as all values match the template values), and delete the Service Template itself.

Workflow

Starting from: Service Templates 👉 Prototype

1. User navigates to /admin/application_settings/services
2. User selects a specific Service Template, like Jira
3. User sees a message at the top of the page informing them that this feature is being replaced by Instance-level integrations, and is guided to migrate/upgrade
4. User clicks on the Upgrade button in banner, the page is redirected to integrations/jira and then sees an upgrade confirmation prompt informing them what will happen when they "upgrade"
5. User clicks the "Upgrade" button in the prompt, taking them to a special New Integration from Template page. [At this point the old Service Template is disabled and all projects that have been inheriting the Service Template will be using the new integration feature]
6. The form is already filled out with the existing Service Template data, and the page indicates how many projects are currently overriding the settings.
7. User sees a toast message informing them that the upgrade was successful
8. (Optionally) When the user hits Save, the user is prompted to choose whether to...
   1. Apply settings only to projects that already inherit the same settings
   2. Force all projects to inherit these settings (even the one with overrides)

Starting from: New Integrations view 👉 Prototype

1. User navigates to /admin/application_settings/integrations
2. User selects an integration, like Jira
3. User is prompted to with a message explaining that they first need to upgrade their Service Template first
4. User clicks the "Upgrade" button in the prompt, taking them the New Jira Integration page. [At this point the Service Template settings are copied over, if there were any and the old Service Template is disabled and all projects that have been inheriting the Service Template will be using the new integration feature]
5. The form is already filled out with the existing Service Template data (if applicable), and the page indicates how many projects are currently overriding the settings.
6. User sees a toast message informing them that the upgrade was successful

This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.