The following 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.
| Stage | Create |
| Maturity | Complete |
| Content Last Reviewed | 2023-11-30 |
Thanks for visiting the category direction page for the GitLab Web IDE. This page belongs to the IDE group of the Create stage and is maintained by Senior Product Manager, Michelle Chen (@michelle-chen).
This direction page is a work in progress, and everyone can contribute:
A code editor is one of the most important tools in a software developer's toolkit. With the Web IDE, we want to meet the developers where they are and offer a mature, feature-rich editing experience in the browser. By replacing the current Web IDE with a browser-based instance of VS Code, the most popular code editor, we can enable developers to complete more complex tasks and work more efficiently inside GitLab.
Software development is an iterative process that involves requesting and responding to feedback from Developers, Designers, Product Managers, or other peers. While a desktop editor is often optimized with extensions to support specific programming languages, coding standards, or frameworks, they are often not ideal for the frequent context switching and rapid feedback cycles in the review phase. GitLab's Web IDE offers a familiar workflow to developers while remaining easy to use for designers, product managers and more. It brings editing capabilities into the context of their current task in GitLab, by providing an editing experience designed for the workflow they're trying to accomplish.
There are three critical workflows we aim to support in the Web IDE.
Configuration
Users who configure projects or GitLab need editing tools to help them be efficient at this process. Creating specialized configuration files for working with GitLab CI or other areas of GitLab benefit from feedback provided directly in the editor.
Configuration files are common to software development and the tools of the DevSecOps life cycle. Files like gitlab-ci.yml or CODEOWNERS can be difficult to manage because they need to be both syntactically (correct commas, quotes, value types etc) and semantically valid (expresses what you intended it to). Local development environments can be configured with syntax checkers, and schemas to help verify syntactic correctness, but lack the context for deeper features.
Once your GitLab CI configuration has been created and validated, it may be responsible for providing review applications for previewing changes, code quality and coverage reports or vulnerability information. As an engineer who is working on a contribution information contained on these reports must be reconciled within their editor.
Contribution
Developers who work on contributing directly to the code in projects need to action feedback from the review process. This often involves leaving MR feedback open in one window while working in an editor in a different window. Feedback in the form of suggestions and patch files needs to be handled outside of the MR interface and back in the local development environment. At the same time some feedback requires manually updating comments and threads that feedback has been actioned after the changes have been pushed back to the MR. Having easy access to the feedback from reviewers and CI jobs inside of the editor should ensure that it's easy to action.
Feedback & Review
The code review process encompasses both engineering personas and non-engineering personas who contribute through design, product and other feedback.
A developer reviewing a merge request often needs to check the code out locally and create an environment for that review. Sometimes this process can be complicated by conflicts with local dependencies, their own local development branch, database migrations and other issues which prevent just cleanly changing branches.
A designer or product manager may not have the time or experience required to set up and maintain an environment to perform reviews. Reviewing these changes inside of a review application is valuable, but it can be hard to provide as actionable comments back to the MR.
In solving for both these users and workflows, it will be important to make sure that people who want to give feedback are able to easily accomplish that.
Strategic Focus Areas To address these themes, we will focus on the following strategic areas, which will resemble phases of the product and work prioritization:
The GitLab Workflow extension for VS Code is available on the Visual Studio Marketplace and enables you to interact with merge request discussions, issues, and pipelines directly from VS Code.
One of the benefits of replacing the Web IDE with a VS Code instance is that you will be able to install compatible extensions in the browser-based Web IDE. By bundling the GitLab Workflow extension in the Web IDE, we will enable new functionality and provide consistency across the desktop and web editing experience. Functionality contributed by the community and additional investments in the capabilities of the extension will then be available on both platforms. The GitLab Workflow extension is maintained by the Editor Extensions group.
While our complete maturity plan also aims to ensure some compatibility with the iPad. We won't be focusing on making the iPad or other mobile devices 1st class devices due to our upstream dependencies on VS Code. We also do not have sufficient evidence to support mobile devices as code creation devices inside the Web IDE. As our research in this area continues to expand we may revisit mobile support.
We do not have plans to bring real-time collaborative coding features to the Web IDE at this time. We'll continue to evaluate the space and may revisit this use case at a later date, especially as it relates to workspaces.
The Web IDE primarily serves engineering personas who are contributing to development, configuring or interacting with continuous integration and reviewing contributions from other team members. Personas like Sasha (Software Developer) and Devon (DevOps Engineer) need tools that allow them to deeply understand the changes and provide meaningful feedback of both comments and code suggestions.
The Web IDE also serves non-engineer personas who are focused on reviewing and providing feedback for contributions. Personas like Parker (Product Manager), Presley (Product Designer), and Delaney (Development Team Lead) need tools and features that help them preform reviews of code, documentation and interfaces without requiring local environments or complex configurations. Feedback should be easy to leave and actionable by engineers within their editor.
The Web IDE is available to everyone on SaaS and Self-managed as part of the Free tier.