Remove legacy Web IDE

Deprecation Summary

The legacy Web IDE is the Vue-based implementation of the Web IDE that was used before migrating to a VSCode-based Web IDE as the default experience on GitLab 15.11. The legacy Web IDE is still accessible if a GitLab instance administrator turns the vscode_web_ide
feature flag off. This feature is has been enabled by default on gitlab.com and self-managed instances since GitLab 15.11.

Documentation

Product Usage

Describe why deprecation of this feature is necessary, ideally with dashboards/metrics that show product usage. add links to the documentation

According to our metrics (internal link), 1% of GitLab instances have the vscode_web_Ide feature flag disabled which means they still use the legacy Web IDE.

  1. The legacy Web IDE has been disabled by default since GitLab 15.11 on both self-managed and SaaS instances. We don't have metrics that capture if self-managed instances have re-enabled it.
  2. The legacy Web IDE hasn't received maintenance work in more than 2 years.

Breaking Change?

If an instance administrator has turned off the vscode_web_ide feature flag in the past, they should turn it on again to start using the VSCode-based Web IDE.

Affected Customers

  • GitLab.com
  • Self-managed
  • Dedicated

Deprecation Milestone

17.9

Planned Removal Milestone

18.0

Links

Checklists

Timeline

Rollout Plan

DRIs:

  • Engineers: @ealcantara
  • Describe rollout plans on GitLab.com
    • _Link to _a feature flag rollout issue that covers:
      • Expected release date on GitLab.com and GitLab version
      • Rollout timelines, such as a percentage rollout on GitLab.com
      • Creation of any clean-up issues, such as code removal
  • Determine how to migrate users still using the existing functionality
  • Document ways to migrate with the tooling available
  • Automate any users who have not yet migrated, but ensure it's a two-way door decision
Communication Plan

DRIs:

Add links to the relevant merge requests.

  • As soon as possible, but no later than the third milestone preceding the major release (for example, given the following release schedule: 17.8, 17.9, 17.10, 17.11, 18.0 – 17.9 is the third milestone preceding the major release):
  • On the major milestone:
    • The deprecated item has been removed.
    • If the removal of the deprecated item is a breaking change, the merge request is labeled breaking change.
    • Document the migration plan for users, clearly outlining the actions they need to take to mitigate the impact of the breaking change.
      • Add link

Development

DRIs:

  • Engineers: @ealcantara
  • Measure usage of the impacted product feature
  • Create tooling for customers to manually migrate their data or workflows
    • add issue link
  • Build mechanism for users to manually enable the breaking change ahead of time
    • add issue link
  • Automate the migration for those who do not take any manual steps (ensure the automation can be reverted)
    • add issue link
  • Develop rollout plan of breaking change on GitLab.com
    • add feature flag rollout issue
  • Dogfood the changes on GitLab.com or a Self-Managed test instance
    • The VSCode-based Web IDE has been the default editor for GitLab since 15.11. Users have to manually opt-out of this alternative to use the legacy Web IDE.
  • (Optional) Create UI controls for instance admins to disable the breaking change, providing flexibility to Self-Managed / Dedicated customers. Optional as this depends on the breaking change.
    • add issue link

Approvals

  • Product Manager @PM
  • Engineering Manager @EM
  • Senior Engineering Manager / Director @senior-eng-leader
  • Group / Director of Product Management @senior-product-leader

Mentions (as applicable)

  • Product Designer @ProductDesigner
  • Tech Writer @TW
  • Software Engineering in Test @SET
  • Any other stable counterparts based on the product categories:
    • Add Sales/CS counterpart or mention @timtams
    • Add Support counterpart or mention @gitlab-com/support/managers
    • Add Marketing counterpart or mention @cfoster3

Labels

  • This issue is labeled deprecation, and with the relevant ~devops::, ~group::, and ~Category: labels.
  • This issue is labeled breaking change if the removal of the deprecated item will be a breaking change.

References

Edited by Enrique Alcántara