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.
|Content Last Reviewed||
Thanks for visiting the category direction page for Remote Development in GitLab. This page belongs to the IDE group of the Create stage and is maintained by Principal Product Manager, Eric Schurter (@ericschurter).
This direction page is a work in progress, and everyone can contribute:
A common obstacle faced by developers when first contributing to a project is the setup of their local development environment. The time-consuming process of managing interrelated dependencies and fixing version compatibility issues can be demotivating, especially for those who only contribute occasionally or switch between multiple projects frequently. In complicated environments, development teams may also impose restrictions, authentication credentials, build procedures, and standards that add to the fragile nature of the development environment.
At the end of the day, developers want to spend less time managing their development environment and more time contributing high-quality code. And at GitLab, our mission is to ensure everyone can contribute. With Remote Development, our goal is to eliminate the responsibility of configuring and maintaining a local development environment.
Ephemeral, cloud-based workspaces will be configured in a single file stored in a repository, allowing you to provision a new environment with a single click and connect securely from the GitLab Web IDE or your desktop editor of choice. Monitoring tools and dashboards will be available in GitLab to manage running and suspended environments, ensuring efficient usage of resources. This will free up valuable development time, streamline onboarding of new developers, and increase security across an increasingly remote workforce.
A cloud-based development environment also 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. GitLab workspaces 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:
We're building Remote Development at GitLab against a few guiding principles:
Developers should be able to define their workspaces in an easy-to-use document format, stored and versioned in a project repository alongside your source code.
Developer tooling is a very individual thing and productivity can depend on having access to the right IDE. In support of this, we aim to meet developers where they are by providing editor-agnostic workspaces with centrally-managed configurations that offer a seamless editing experience either from the GitLab Web IDE or your local IDE.
Our initial iterations for Remote Development will be focused on a "bring your own cloud" solution, letting developers on both GitLab.com and Self-managed GitLab instances provision workspaces on their existing cloud platforms like Amazon Web Services, Google Cloud Platform, or Azure Cloud Services. We will eventually offer a fully-managed option within GitLab, provided as a service billed based on consumption, much like our Runner SaaS offering.
In 2023, we are focused on reaching a secure, production-quality, Viable Remote Development offering.
Workspaces are personal and ephemeral. We anticipate developers will want to collaboarte within workspaces but we are not currently focused on providing a real-time collaborative editing environment suitable for pair programming.
Most developers today use Visual Studio Code (VS Code) as their editor of choice, so our initial focus will be on providing support for that ecosystem. Establishing a client/host connection between VS Code and VS Code Server is architecturally simpler and provides a seamless experience for developers already familiar with VS Code. However, support for other IDEs like vim, JetBrains editors, Jupyter Notebook, Xcode, or others, will be added as the solution matures and we work toward our goal of an editor-agnostic solution.
The term "Remote Development" speaks to the challenges faced by software developers and those who lead or support their teams. By providing a mature remote development solution, the technical barriers to collaboration are lowered, allowing non-developers to make effective contributions as well. This enables us to cater to all user personas described in our handbook, with a 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.
Priyanka (Platform Engineer) targets users who define pipelines, templates, and processes to improve developer efficiency across an organization.
Remote Developement 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.
With GitLab Premium, organizations will have the ability to specify development environments in a
devfile and create remote environments on existing cloud infrastructure. This will allow team leads or DevOps engineers to monitor multiple environments from a centralized GitLab dashboard and standardize the environment across the organization, improving 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.
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