By Sven Efftinge, Co-Founder and CEO of Gitpod

Modern engineering teams communicate, deploy, integrate and version control their work on a server-based development pipeline and all our tools, such as Git hoster, issue trackers, CI/CD, monitoring, tracing, etc. are accessible through a browser from any device.

Only the actual coding itself is still happening on local machines, forcing us to manually turn our computers into environments capable of running today's complex software systems. How come we are still living with all the imposed drawbacks such as tedious configuration, waiting for builds, restricted collaboration and reproducibility issues? It's time for a change.

With the advent of tools like Kubernetes and browser-based IDEs such as VS Code we finally have all prerequisites in place to run a professional editor in a browser, providing the full feature set of the most popular desktop IDE on the planet and connect it to secure and fast containers running in the cloud.

This allows to fully automate the provisioning of development environments and thereby speed up development cycles (lead times), streamline onboarding and eliminate reproducibility issues.

In addition, Continuous Dev Environments apply the lessons learned from CI/CD. The idea is to integrate the preparation of dev environments into your GitOps pipeline so that disposable dev environments get prepared continuously on every change. As a result, your team members can spin up fresh fully initialized environments for each new task. Fully initialized means that the right branch is checked out and all necessary build steps are already executed on top.

In the following, I share my top 5 reasons why dev teams should adopt continuous dev environments:

1. Shorter Lead Times - Usually lead time refers to the time that passes between a change landing in the git repository and the moment it is deployed to production. Most professional teams have an automated CI/CD pipeline in place that runs through builds and tests, then waits for a team member to review and approve the change set, before it deploys the new version to a staging or production environment.  Continuous dev environments further speed up this process because team members can pick up a task and start coding instantaneously. Also, code reviews are more efficient and convenient: you don't need to manually checkout a certain branch locally and rebuild everything, possibly staging your current work. Instead you can just launch a fresh dev environment for every code review and any task with a single click.
2. Easy Onboarding - If you want to welcome new teammates or external contributors properly, you should make it super easy to get started. As a consultant I've been working on many different projects over the years. Setting up my machine was always painful and burned not only my own energy, but also distracted  colleagues that I had to ask for help. Furthermore, the onboarding process is not only relevant for new team members but also, when someone makes important changes to the set up, you need to go back to an older branch, or you come back from a two week vacation. Having an automated setup eliminates any onboarding friction allowing you to focus on what really matters: writing quality code.
3. Reproducibility - The ubiquitous "Works on my machine" meme is probably one of the most popular examples of what kind of problems manual setups cause besides just being time-consuming and tedious. Surprising behavior that we cannot reproduce in our local dev environment is something developers have lived with forever. As software systems become more complex, even subtle differences can cause unexpected  behavior. Running and developing your software system on an infrastructure that is described in executable configuration, versioned together with the rest of the code, will ensure the environment works the same for everyone.
4. Secure Remote Work - Remote work has been popular among development teams even before Covid-19. But these days it has become a requirement. GitLab recently asked their Twitter followers whether they use their own hardware or get them provided by the employer. Given that over 70% rely on at least some personal equipment when working remotely, the friction of setting up dev environments locally becomes even more tedious. There's another advantage: security. Source code is an important asset for most companies and having copies of it sitting on local disks in unsecured networks around the world is a serious risk. A cloud-based dev environment provides a sliding window to the source code secured by an encrypted connection. Developers never need to download the source code to their local machine anymore.
5. Remote Team-Work - Having a web-based solution makes it obviously easy to work closely together as a remote team. Pair programming in the same development environment, accompanied by a Zoom session is a great way to hunt down hard to find bugs or do code reviews together. The possibility to create snapshots of dev environments further allows engineers to collaborate asynchronously. As you can freeze any state you are in and share it via a link in an issue or Slack. Teams can automatically recreate tricky situations in their dev environments, do some further investigation and share a new snapshot back. It's similar to git's branching model but for the full environment.
   

For Me, There is no Going Back

Once experienced, the ease of mind that you get when you can always launch a ready-to-code development environment in a few seconds for any branch, any project and from any device is something I don't want to miss anymore.

What  has really changed how I work is the disposable nature of such development environments. Software engineering is inherently asynchronous with most changes going through multiple iterations of a development and review cycle. Being able to spin up a dev environment for even the smallest task is eliminating just so much friction. You can easily have multiple dev environments running in parallel without the need to ever manually sync git changes and re-run the full build as all of that is prepared in the background.

##

About the Author

Sven Efftinge, Co-Founder and CEO of Gitpod

Sven Efftinge is the Co-Founder and CEO of Gitpod. He initiated and led many open-source projects like Xtext, Theia and Gitpod. Sven has over 10 years experience in tool developing, language design and project management. Together with Moritz Eysholdt and Dr. Jan Köhnlein, he founded TypeFox, the specialist for language engineering. In his free time he enjoys to go kiting and to spend time with his family.