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.
| Section | Stage | Maturity | Last Reviewed |
|---|---|---|---|
| Dev | Create | Planned | 2022-10-27 |
This is the direction page for the Remote Development category, part of the Create stage of the DevOps lifecycle. This page is maintained by Eric Schurter (@ericschurter, eschurter@gitlab.com) Senior Product Manager for the Editor group.
Like most other category direction pages, this page will be continuously updated based on market dynamics, new data points, and customer conversations. Sharing feedback directly on the category direction epic or specific issues contained within is the best way to contribute to our strategy and vision.
One of the first barriers to overcome before contributing to a project is configuring your local development environment. The time-consuming task of managing related dependencies and troubleshooting incompatible versions can be discouraging, especially for someone working who contributes infrequently or works on multiple projects. In more advanced environments, a development team may even have a standard set of tools, extensions, and configuration files, adding to the delicate nature of the development environment.
The GitLab Web IDE allows for anyone to contribute to a project right from their web browser. This makes contributing simple fixes to an existing project or responding to feedback in a merge request quick and effective. However, without code linting, real-time rendered previews, or the ability to run tests, many developers are unable to complete meaningful work in the Web IDE. The Web Terminal and Live Preview features offer some additional functionality for a narrow set of use cases, and code changes in the Web IDE can trigger a pipeline, but that doesn't provide the immediate feedback necessary for efficient development.
Developers want to spend less time managing their development environment and more time contributing high-quality code. And at GitLab, we want everyone to contribute. Eliminating the responsibility of configuring and maintaining a local development environment frees up valuable development time and streamlines onboarding of new developers joining the team. For developers working on larger teams, or those contributing to multiple open source projects, the cost of switching contexts can be so high that it discourages collaboration. With an on-demand, cloud-based development environment code reviews are less of a disruption because developers can move more quickly from project to project and sensitive data is securely stored in the cloud rather than distributed across numerous local devices.
In addition, the global COVID-19 pandemic has accelerated the shift toward remote and hybrid workforces, increasing the emphasis on privacy and security. A cloud-based development environment enables organizations working in regulated industries to enforce a zero-trust policy that prevents source code from ever being stored locally while maintaining a high quality developer experience. Remote development environments also contribute to our vision for managing Software Supply Chain Security by providing a single place where dependencies and tools can be audited and verified and access to those environments can be controlled through strong authentication.
In this short (9-minute) video, Eric Schurter walks you through the goals and technical approach for the Remote Development category:
Remote Development, as the name suggests, directly targets software developers and those who manage or support teams of developers. However, a mature remote development offering lowers the technical barrier to collaboration and enables non-developer personas to effectively and efficiently contribute. As a result, we are able to target all the user personas we describe in our handbook, with a particular focus on:
Sasha (Software Developer): targets full time contributors to all types of projects (commercial, OSS, data science, etc.). These users expect and need a high level of reliability and speed in their interactions with both project files and Git.
Delaney (Development Team Lead): targets users who often times have elevated roles which allow for the management of project settings, such as access control, security, commit strategies, and mirroring.
Devon (DevOps Engineer): targets engineers tasked with supporting and enabling software teams. Their tasks often revolve around platform creation and maintenance, where GitOps] workflows are crucial.
As we bring this feature to a viable maturity level, we'll have to tackle these major challenges:
Our goal is to eliminate the need to configure and maintain complex local development environments by providing secure on-demand environments in the cloud. Developers, however, have very specific requirements and individual preferences for how they configure their editors and environments. In support of this, we aim to meet developers where they are by providing editor-agnostic development environments with centrally-managed configurations and a seamless transition between editing either from the Web IDE or in your local IDE.
By offering an end-to-end remote development solution within GitLab, we are uniquely positioned to gracefully extend the editing experience as the needs arise, reducing costs without sacrificing speed or quality. The GitLab Web IDE is ubiquitous and free for everyone, a fully-featured web-based editor enabling everyone to contribute from any web browser. As you need to make more complex changes or require a runtime environment to compile code, the Web IDE will connect seamlessly to a "headless" remote environment, reducing the need for context switching. And once we have access to these remote environments, we also unlock functionality that can bring other stages of the DevOps workflow closer to the developer and integrated in the Web IDE.
These development environments will be configured in a single file stored in a repository, allowing you to provision a new environment on your existing cloud infrastructure with a single click. Monitoring tools and dashboards will be available in GitLab to manage running and suspended environments, ensuring efficient usage of resources. Eventually, we intend to offer GitLab-hosted shared infrastructure as well, abstracting away the burden of cloud service administration and simplifying billing.
As we iterate on our technical approach, we're validating against a handful of guiding principles:
As you take on more complex editing tasks, the GitLab Web IDE will grow with you.
As we finalize our investigation of the underlying technologies and polish our initial proofs of concept, we are focused on shipping the new VS Code-based Web IDE and making our MVC broadly available, building an iteration plan for our more complete solution, and validating our reference architecture with customers.
The major focus areas right now are:
Bring-your-own Cloud
Our initial iterations will be focused on integrating with existing cloud providers like Amazon Web Services (AWS), Google Cloud, or Microsoft Azure to provide a solution for those who already have access to cloud compute. We will eventually look to offer a fully-managed option within GitLab. This is likely to be provided as a service billed based on consumption, much like our Runner SaaS offering.
Packaging and Pricing
Remote Developement as a category will be a multi-level offering, providing value across all tiers and distributions.
Free tiers will be able to securely connect the Web IDE to a remote environment that is manually configured with a compatible code server and authentication token. We will provide detailed documentation and a configuration script to reduce friction in the configuration of the server.
In addition, Premium tiers will be able to define an environment as code in a devfile, use that file to provision remote environments on an existing cloud infrastructure, and monitor multiple environments from a GitLab dashboard. Team leads or DevOps Engineers will be able to define a standardized environment across their organization and improve team efficiency.
Eventually, Ultimate tiers will have access to advanced monitoring and auditing tools, providing insight into usage across the organization and enforcing security best practices through development tooling.
Note: Our pricing strategy is still being researched and validated. This strategy may be subject to change.
Our approach to Remote Development involves a few core components working together that enable a seamless experience:
This high-level diagram illustrates how the components of the remote development offering fit together.
While we want to provide an editor-agnostic solution, our initial iterations will focus on support for VS Code. The vast majority of developers are using VS Code and facilitating the connection between a VS Code client and host simplifies the architecture. Support for vim, JetBrains editors, Xcode, or other IDEs will come as the category reaches Complete or Loveable maturity.
This category is currently Planned with no specific date for moving to Minimal.
As part of the Web IDE strategy, the Editor group is working toward replacing the existing Web IDE with a browser-based instance of VSCode.
Watch here as Paul Slaughter and Eric Schurter from the Editor group discuss the proof of concept and the various user experience benefits it provides.
Parts two, three, and four of the VSCode demo focus on extensions, performance, and customization, respectively.
A more mature browser-based IDE is the first step toward a mature remote development platform. One potential path we may take would be:
The three most relevant competitors in this area are GitHub Codespaces, Gitpod, and Coder. Each one offers a slightly different take on remote development environments but aim to solve very similar problems.
These companies and projects are also related to the remote development space:
Several analysts have recently published reports highlighting the rapid adoption of cloud-based development workflows.
Gartner report titled, Hype® Cycle for Agile and DevOps, 2021 discusses "Browser-based integrated development environments (IDEs) are consumed “as a service.” They enable browser-based remote access to a complete development environment, which obviates the need for local installation/configuration."*
Further, it states "Browser-based IDEs provide consistent, secure access to preconfigured development workflows to developers. This frees them from setting up their own environments, eliminating the need to install and maintain prerequisites, software development kits (SDKs), security updates and workstation plug-ins."*
"Gartner predicts that, by 2026, 60% of cloud workloads will be built and deployed using browser-based IDEs". The report adds, “Five factors are driving their increased adoption":
*Gartner, Hype Cycle for Agile and DevOps, 2021, George Spafford, Joachim Herschmann, 12 July, 2021. GARTNER and HYPE CYCLE are a registered trademark and service mark of Gartner, Inc. and/or its affiliates in the U.S. and internationally and are used herein with permission.
GitLab's Web IDE already addresses some of Gartner's recommendations, by providing a platform from which anyone can contribute. By migrating the Web IDE to VSCode, we can rapidly increase the complexity of work and meet the needs of more serious development tasks. Pairing that with a Server Runtime, GitLab is positioned well to meet our customers' expectations when it comes to security, agility, and flexibility.
451 Research published an analysis of Coder and their approach to moving development workspaces to the cloud. 451 Research recognizes that "by moving developers, IT operators and others to the cloud, organizations can drive faster releases, productivity and efficiency by automating and abstracting IT environments and their management. The idea is that developers have more time to focus on new features, applications and innovation when they are unencumbered with setting up and running their own environments."
In the analysis, 451 Research cites results from their 2021 report, Voice of the Enterprise: DevOps, Workloads & Key Projects, that reveal a significant shift in the primary DevOps implementation environment, moving away from On-premise and Hosted Private Cloud workspaces to SaaS and Public Cloud over the next two years.
451 Research's recommendation to stay competitive in this space is to "focus on enabling simplicity, speed and productivity for developers," something GitLab's single platform for DevOps is positioned well to deliver.
Source: 451 Research, a part of S&P Global Market Intelligence, Coverage Initiation: Coder moves development to the cloud with workspaces-as-code, September 2021, All Rights Reserved