このページの情報は古くなっている可能性があります。 最新の情報は 本家サイト でご確認ください。
| Stage | Create |
| Maturity | Viable |
| Content Last Reviewed | 2020-08-12 |
Thanks for visiting this direction page on the Web IDE in GitLab. This page belongs to the Editor group of the Create stage and is maintained by Kai Armstrong (E-Mail).
This direction is constantly evolving and everyone can contribute:
Code Editors are one of the most important tools in a software engineers toolkit because the majority of their work is writing and working with code. They're customized with extensions for programming languages, coding standards and frameworks and more for the type of working being done. They're also optimized for connecting to development runtime environments and services engineers need to do their work. The context in which engineers use this tool dictates the type of configuration required.
Software development is an iterative process that involves requesting feedback from peers (Developers, Designers, Product Mangers etc), and responding to that feedback. In GitLab, this is done using a Merge Request. Reviewing is in fact a specialized editing task (other professions would call this same task editing), for example suggesting specific changes to functions, documentation, and interface text. A local development environment is often not ideal for these editing tasks:
Configuration files are also common to software development and the tools of the DevOps life cycle. Files like gitlab-ci.yml or CODEOWNERS can be difficult to use 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.
GitLab CI is fast and highly configurable within GitLab, but it can be hard to remember all the configuration parameters for your goal and a typo can make the complete configuration invalid. Editing this file often involves having documentation open while make changes. Once those changes have been made users leave their editor to validate the file or commit and wait for feedback from a running pipeline.
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.
The Web IDE is GitLab's editing tool; it is familiar to developers, and 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.
The software development process involves many people working across various parts of configuration, contribution and review. All of these users work together to advance software projects in their organization.
Engineering personas who are contributing to development, configuring or interacting with continuous integration and reviewing contributions from other team members. Users performing these tasks need tools that allow them to deeply understand the changes and provide meaningful feedback of both comments and code suggestions. These are specifically addressed by the following GitLab Personas:
Non-Engineer personas who are focused on reviewing and providing feedback for contributions. These users 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. These are specifically addressed by the following GitLab Personas:
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.
Contribution Engineering personas who work on contributing directly to the code in projects need to action feedback from the review process. Having easy access to the feedback from reviewers and CI jobs inside of the editor should ensure that it's easy to action.
Review The code review process encompasses both engineering personas and non-engineering personas who contribute through design, product and other feedback. In solving for these users it will be important to make sure that people who want to give feedback are able to easily accomplish that.
Editor configuration and customization are important parts of IDE experiences. Teams working together often standardize editor configurations through the use of an .editorconfig file and developers customize other aspects of the editor to their own preference. Ensuring support for various syntax highlighting preferences and colorization will make working in the Web IDE feel more like a user's local editor.
Providing first class support for editing specialized GitLab files like .gitlab-ci.yml file, issue templates and CODEOWNDERS ensures developers have the tools needed to efficiently accomplish their goals.
Extending the Web IDE to support other GitLab features like executing CI Jobs and integrating review app preview will help provide more feedback to changes in the Web IDE.
Documentation is a less intensive type of engineering effort that requires fewer tools than traditional development environments. Enabling technical users to produce documentation in the Web IDE easier and more quickly will be important as we continue to expand the Web IDE. This includes enhancing markdown tooling and support for more prose based content in the Web IDE.
When working through the code review process users are often trying to understand feedback in the context of their changes. Engineers must examine feedback in one window and then return to their editor to make changes. By expanding code review tools in to the Web IDE we can help provide that review feedback in the Web IDE so that changes can be made more easily.
It's also important to help users quickly jump to definition and find references while reviewing and editing code within the Web IDE. Supporting code intelligence features in the Web IDE will move that vision forward.
Currently, GitLab's maturity in the Web IDE is viable. Here's why:
A complete Web IDE category ensures that the Web IDE is used for tightly integrated editing experiences in GitLab. Moving beyond the focus will be on standardization of editing environments through the use of .editorconfig and support for user syntax highlighting (including dark mode). Finally, the Web IDE must provide 1st class editing experiences for GitLab features.
Part of a Lovable Web IDE comes by providing support for the Code Review process inside of the Web IDE. This involves support for both leaving and responding to feedback inside of the Web IDE. The Web IDE should also include code navigation features like Jump to Definition and Find References to better support this process.
We prioritize efforts in the Web IDE that further tighter integrations with other areas of GitLab. We're particularly focused on tighter integrations with code review and GitLab CI/CD.
In Progress: Support custom JSON schema validation in the Web IDE #226982
Following up on schema validation for .gitlab-ci.yml, bringing support for custom defined schema will allow teams to more effectively collaborate on standard files in their projects.
In Progress: Use one editor experience for all file/code editing &498
Standardizing on a single editor experience supported by our use of Monaco will allow us to bring a consistent experience to users in both the Web IDE and single file editing modes like Snippets or GitLab CI.
Upcoming: Web IDE button in diff tab of Merge Request #21654
When reviewing a merge request it can be helpful to see the complete context of all changes and edit across files.
We're not currently focused on solving the needs of non-engineering based personas with the Web IDE. Non-engineers require a different type of editing experience and that can largely be focused around different types of content. These editing experiences may include documentation or notes based in Markdown, or more WYSIWYG experiences related to content management systems. The Static Site Editor group will be more focused on these efforts.
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 Monaco and various mobile OSs. 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.
Live Preview improvements in the Web IDE is currently blocked by an investigation of using service workers for providing updated content and assets to the Live Preview service. This investigation is currently pending consultation from a third party who provides a core library to this service.
We'd ultimately like the ability for remote development environments to be attached to the Web IDE, but will be addressing this work in the Editor Extension category. This work will likely be prioritized behind the ability for remote development environments connected to a local VS Code editor.
The Editor group does not have plans to bring real-time collaborative coding features to the Web IDE at this time. While we previously outlined this as a category to focus on, we don't believe there is enough market demand to warrant investment. We'll continue to evaluate the space and may revisit this use case at a later date.
Currently the Analyst landscape is fragmented on cloud native development experiences. This market will continue to mature as Microsoft pushes ahead with VS Code Online and Amazon further integrates Cloud9 in to their offerings.
https://www.g2crowd.com/categories/integrated-development-environment-ide https://www.theserverside.com/news/450433105/AWS-Cloud9-IDE-threatens-Microsoft-developer-base
Top user issues relate to the configurability and customization of the Web IDE. These focus on items like standardizing editor coding style through configuration files and supporting user customization for themes and other preferences.
.gitattributes and .editorconfig for correct encoding #14222GitLab's current internal usage of the Web IDE is very heavily focused around non-technical personas and so there are not any current issues. As we look towards delivering on an IDE for technical users we'll update this section as appropriate.
The most important items to delivering on the Web IDE Vision are:
It will also be important to standardize current editing experiences on a single editor to provide more parity across all types of edits.