Developing an application is quite a pleasurable task. When you get in the zone, you can achieve some of your best work.
Some people have to have the perfect playlist, others need the perfect lighting, chair, or anything else imaginable under the sun.
What does every developer have in common? An IDE! With preferences of course.
Cloud Development Environments
Did you know you can run modern IDEs straight from your browser via CDEs? Coder, Gitpod, Theia, just to name a few. This means you can have the same developer experience regardless of the machine you're using! And most of them are based on VS Code, which is the most popular IDE out there.
In our company, we're not only using Web IDEs, we're using ephemeral workstations! This means that our workstations get thrown out at least daily, and a shiny new one is provisioned.
Why do you think you may need persistence during development:
- Persist code changes. A VCS (e.g. Github) is much better suited at this
- IDE customization. Can be tied to your profile rather than machine.
- Install tools. This is the responsibility of the OS, not the IDE
- Store temporary files. This is not the responsibility of the IDE is it?
By using ephemeral Web IDEs, this is what we have observed.
Every developer uses the same environment, literally. The same versions of the tools, compilers, etc. There is a significant, if not complete, removal of situations where things "work on my machine".
Tenure is no longer relevant, in the sense that there is no accumulation of "magic configurations" in a developer's machine.
Most web IDEs are a small-ish package that can be run on any machine.
What solutions such as Gitpod allow you to do is create your own workstation image. All of the sudden you have a single place where you manage your tools and dependencies. Be it a Dockerfile, NixOS, or in our case simply Debian's package manager, when we update our tools, everyone gets it.
Time to first commit
In a consistent environment where everyone starts from scratch every day, the "initial setup instructions" are always up-to-date. In fact, through the use of tasks, there are virtually no manual steps required to start developing. It has been a significant developer experience improvement.
It effectively has translated to developers being able to commit on their very first day!
As an pleasant side effect, we can use the very same image to run our CI build agents on, guaranteeing that they are also kept up-to-date and that they're using the same versions as the developer machines.
With the developer experience out of the way, we get to focus on the task at hands. As a newcomer, you can go straight to pairing! As a seasoned developer you get to focus on your task rather than the surroundings.
You have the chance to ensure that everyone in your team is keeping up-to-date with the latest fixes and patches. You need not worry about that team member that never has time to update their machine, because now, every time anyone starts working, they get a shiny new and updated machine.
Note that we're referring specifically to the IDE and underlying container. If you or your colleagues do not do their part in keeping your machines up-to-date, you're asking for trouble regardless of what you do.
As a side effect, you benefit from reverse uptime. This mitigates persistence attacks, prevents outdated versions of software from lingering around or growing stale, and avoids temporary development data (e.g. bug reproduction data) from being kept indefinitely.
Care is needed
Do not neglect the fact that even though ephemeral, and accessible from a browser, your workstation is running somewhere. Do you trust that place? It can be a service provider, it can be your own infrastructure.
It is your responsibility to ensure a secure development environment.
It is understandable that not every solution suits all use cases. Ephemeral IDEs offer a new and exciting way of developing in a consistent fashion regardless of where you are, with tangible, concrete, and positive security implications and real world productivity impact.