## Closed We've decided to move away from maintaining the maturity levels with the epic hierarchy. Sub-epics and issues should now be created under https://gitlab.com/groups/gitlab-org/-/epics/7419+ root. See High Level Planning for decision trail https://docs.google.com/document/d/1Xfr5YHdStC7_3kVAognj0SxbXlcavj2ofgp1mH2zH4U/edit?tab=t.0#heading=h.tpfj927nd26f. ## Problem to solve &amp;9189+ outlines the scope for the Remote Development minimal maturity and includes the ability to connect the GitLab Web IDE to an externally-managed remote environment configured as described in our documentation. While this unlocks new possibilities for developing within the GitLab UI, it does come with a significant limitation: You have to have access to and know how to manage your environment entirely outside of GitLab. As a solution to the larger problem of managing complex local environments, it is truly an MVC. A more viable Remote Development feature will need to do more than shift the burden from manually managing a local environment to manually managing a remote environment. We need to have a way, within GitLab, to define, provision, and interact with remote environments in an accessible and approachable way. ### Viable Maturity As outlined in the GitLab Handbook, Viable maturity means: > <span dir="">Significant use at GitLab the company. </span>[CM Scorecard](https://about.gitlab.com/handbook/product/ux/category-maturity-scorecards/)<span dir=""> at least 3.14 for the </span>[job to be done (JTBD)](https://about.gitlab.com/handbook/product/ux/ux-resources/#jobs-to-be-done-jtbd)<span dir=""> when tested with internal users. No assessment of related jobs to be done. Suitable to replace the need for existing tools for new namespaces, projects, and environments.</span> To get here, we need to be able to get work done at GitLab without ever having to clone a project locally. If we can do work on `www-gitlab-com`, `gitlab-docs`, or `gitlab-org`, then we can assume contributors to projects of similar complexity will be able to use the feature as well. ## What makes this Viable? The goal is to replace a local development environment. So, being viable means that for some projects you can develop entirely within the GitLab UI. This means we should be able to: * Define a remote environment in a file hosted in a project repository * Use the configuration to provision an ephemeral environment on an external cloud platform (AWS, GCP, or Azure) * Securely connect to the new environment from the GitLab Web IDE or via SSH from your local machine * Receive realtime feedback from the terminal and preview changes in real-time (without requiring a CI build) * View a list of environments that I have created * Support for VS Code as the primary editor * Integration with the GitLab Workflow extension * Manually suspend or destroy an environment At the very least, we should be able to do this on `www-gitlab-com` and `gitlab-docs`. A ~Stretch goal is to make it possible to use the GDK and develop on `gitlab-org`. ## What's not in scope? While all of these features are part of our long-term direction, we won't need them to reach a viable maturity. Some may come earlier anyway, but in order to widely adopt a remote development workflow within GitLab we do not need: * Compatibility with other editors like JetBrains, Theia, Xcode, or Visual Studio. * Support for non-Kubernetes-based deployments * Advanced data isolation * Integration with the GitLab CLI for managing environments locally * Options for specifying varying levels of compute in the configuration file ## Availability Remote Development is a multi-tiered category. The features described in this epic are primarily going to be available on ~"GitLab Premium" and interact with existing cloud platforms provided by the customer. ## Assumptions & Unknowns There is still a lot we do not know about how remote environments will be adopted and what features constitute a truly viable offering. We will challenge our assumptions by defining our core JTBD and measuring them with a [Category Maturity Scorecard](https://about.gitlab.com/handbook/product/ux/category-maturity-scorecards/). Key assumptions that may change the scope of this epic: * To what extent do we need to support non-Kubernetes based infrastructure at this maturity level? For significant GitLab usage, we may not need support for bare metal VMs or Kata containers. * Can we run the GDK on it? Is that necessary for wide adoption internally? * What's the length of time someone is willing to wait for a new environment to be created? Do we need an extensive pre-build strategy or is providing a dockerfile in the repository a sufficient solution? * Do we need additional support for passing secrets, credentials, secure variables? * Do we need additional features around the container registry?