Was sind RDEs?
Zuallererst muss unterschieden werden zwischen Remote Development und Remote Development Environments (RDEs).
Bei Remote Development geht es um die Grundidee, dass Software-Entwickler_innen auch im Home Office oder von jedem Ort der Welt und gemeinsam mit weit entfernten Personen an Softwareprojekten arbeiten können. Das ist bereits seit vielen Jahren Standard, hier waren Softwareunternehmen anderen Branchen schon seit vielen Jahren weit voraus.
Allerdings: die allermeisten Software-Entwickler_innen arbeiten immer noch lokal auf ihren Laptops. Source Code wird lokal ausgecheckt, neuer Code in der lokalen IDE geschrieben und debuggt, und die zu entwickelnde Software lokal gebaut und getestet. Wenn die Entwicklerin mit ihren Code-Änderungen zufrieden ist, committed sie diese in das Versionskontrollsystem – sodass nun andere Entwickler_innen den geänderten Code bei sich auschecken können.
Damit findet der Großteil der Arbeit von Softwareentwickler_innen immer noch ganz “old school” am eigenen Rechner statt. Teils getrieben durch die Corona-Pandemie bieten viele Unternehmen Mitarbeiter_innen in verschiedensten Rollen komplette remote-Arbeitsplätze an, und ein immer breiter werdendes Set an Cloud-Tools. Der eigene Rechner wird immer unwichtiger. Ein Teil oder gar sämtliche Arbeit kann für viele Wissensarbeiter_innen inzwischen von jedem Endgerät durchgeführt werden.
Nicht so für Software-Entwickler_innen, die immer noch eng an ihre oft teuren und leistungsstarken Laptops gebunden sind. Viel Zeit und viele Nerven werden investiert, um lokale Entwicklungsumgebungen aufzusetzen und am Laufen zu halten. Fehlerbehandlung ist für jede lokale Entwicklungsumgebung anders und damit sehr aufwändig.
Wo bleiben die Werkzeuge, die es auch Software-Entwickler_innen erlauben, vollständig remote und losgelöst vom lokalen Rechner zu arbeiten?
Hier kommen RDEs ins Spiel.
RDEs sind Remote-Umgebungen, in denen Entwickler_innen alle Tools zur Verfügung haben, die sie für ihre Arbeit brauchen. Eine RDE ist also ein Werkzeug, das Remote Development ermöglicht und einfacher macht. RDEs haben den Anspruch, lokale Entwicklungsumgebungen obsolet zu machen.
Remote Development Environment bedeutet nicht zwingend, dass diese Umgebungen in der öffentlichen Cloud oder als SaaS Produkt zur Verfügung stehen.
Remote bedeutet mal nur, dass die Entwickler_innen nicht lokal auf ihrem Laptop oder Rechner arbeiten, sondern sich zu einer anderen Umgebung verbinden. Diese kann sich im Rechenzentrum des Arbeitgebers befinden, oder in der Private Cloud des Arbeitgebers, oder ein SaaS Angebot darstellen. Verschiedene RDEs bieten hier verschiedene Optionen an.
Warum RDEs?
Das Einrichten einer lokalen Entwicklungsumgebung ist die erste Hürde, die Entwickler_innen zu überwinden haben, bevor sie zu einem Softwareprojekt beitragen können.
Diese meist sehr zeitaufwändige Aufgabe umfasst das Installieren und Einrichten von grundlegenden Entwicklerwerkzeugen wie einem Editor oder einer IDE und eines Versionskontrollsystems, sowie – und hier wird es meist schwierig – die Installation der zu entwickelnden Software und aller ihrer Abhängigkeiten.
Mehr dazu: Der Unterschied zwischen IDEs, lokalen Entwicklungsumge-bungen und RDEs
Meist kommt noch eine Reihe an weiteren Schritten hinzu (z.B. Einrichten von WSL oder Docker oder das Anbinden an CI/CD Pipelines etc.). Das erstmalige Einrichten einer lokalen Entwicklungsumgebung dauert, je nach Komplexität des Softwareprojektes, zwischen zwei Tagen und mehreren Wochen. Erst dann kann ein_e Entwickler_in beginnen, Code zu schreiben.
Ist die lokale Entwicklungsumgebung einmal eingerichtet, berichten Entwickler_innen von kontinuierlichem Aufwand, um diese zu warten. In einer Umfrage unter Gitlab Usern berichten 61% der befragten Entwickler_innen, dass sie zumindest einmal im Monat Zeit zur Problembehandlung mit ihrer lokalen Entwicklungsumgebung aufbringen – 31% sogar zumindest einmal pro Woche.
Zusätzlich zur so verlorenen Zeit, welche die Produktivität von Softwareentiwickler_innen signifikant reduziert, zehrt die Wartung lokaler Entwicklungsumgebungen auch an der Motivation: Problembehandlung der lokalen Entwicklungsumgebung ist sehr unbeliebt.
Standardisierte remote Entwicklungsumgebungen (RDEs) lösen dieses Problem. Entwickler_innen erstellen im Self-service Entwicklungsumgebungen, über die sie in Minutenschnelle produktiv werden können. Das erleichtert auch die Arbeit an mehreren Projekten, Komponenten und Versionen sowie die Zusammenarbeit mit externen Mitarbeiter_innen, da der Source Code und Daten sicher und zentral verwaltet auf den RDEs verbleibt und nicht auf lokale Rechner kopiert wird.
Mehr dazu: 5 Vorteile von Remote Development Environments
Dabei unterscheiden sich verschiedene RDE Angebote darin, was für Möglichkeiten sie bieten.
Was können RDEs?
“For as long as it’s been around, the Web IDE has been held back by the lack of a runtime environment” – Eric Schurter, Senior Product Manager at Gitlab (https://youtu.be/apgU0y-u4A8)
Die RDE Angebote von Github, Gitlab, Gitpod und JetBrains zielen vorrangig darauf ab, Web IDEs mit einer Runtime zu versehen, sodass “volle” IDE Funktionalität über den Browser zur Verfügung steht. Die untenstehende Tabelle gibt einen Überblick, was eine lokale IDE üblicher Weise an Funktionalität bietet, im Vergleich zu momentanen Web IDEs sowie dem RDE Konzept von unterschiedlichen Anbietern.
Dabei bleibt aber weiterhin eine große Lücke zwischen dem, was eine Web IDE mit einer dahinterliegenden runtime Umgebung leisten kann, und dem, was mit einer lokalen Entwicklungsumgebung möglich ist.
| Feature | Web IDE | Lokale IDE | Github, Gitlab, Gitpod, JetBrains RDEs | Lokale Entwick- lungsumgebung (custom) | Cloudomation RDEs | CI/CD pipeline |
|---|---|---|---|---|---|---|
Source Code Editor | ||||||
Syntax Highlighting | ||||||
Autocomplete | ||||||
Source Control (integration) | ||||||
Build: interpreting or compiling and executing code | - | |||||
Debugging | - | |||||
Unit tests | - | - | - | |||
Running full application | - | - | - | |||
Integration tests | - | - | - | |||
Packaging | - | - | - | - | - | |
Deployment | - | - | - | - | - |
Remote Development Environments vs. Local Development Environments
In diesem Vergleichs-Dokument erfahren Sie im Detail, was die wichtigsten Unterschiede zwischen Cloudomation RDEs und lokalen Entwicklungsumgebungen sind.
Jetzt herunterladenCloudomation RDEs
Unser Anspruch ist es, RDEs zur Verfügung zu stellen, die vollwertig äquivalent mit lokalen Entwicklungsumgebungen sind. Dabei geht es vorrangig darum, komplexe Applikationen wie z.B. große Monolithen, nicht-containerisierte Software oder Software mit mehreren Komponenten, in der RDE zu betreiben.
Benutzerfreundlichkeit für Entwickler_innen steht im Vordergrund: voller Zugriff und volle Anpassbarkeit der RDEs für die Entwickler_innen sowie ein Arbeiten, das nahezu ununterscheidbar vom lokalen Entwickeln ist. Zentraler Aspekt ist hierbei die Möglichkeit, einen beliebigen lokalen Editor, eine lokale oder Web-IDE zu verwenden, und die Integration mit der Cloudomation RDE über mehrere Wege zu ermöglichen: über einen mounted file share mit sourcen für lokale Editoren / IDEs oder über ssh für Web- / remote-IDEs.
Build von noch nicht committeten Zwischenständen, Wiederverwendung bereits vorhandener lokaler Build Tools (der z.B. Code nicht minimised) und komfortable Inspektion von Logs runden das Bild ab.
Die besondere Stärke von Cloudomation besteht in der umfassenden Automatisierungs- und Integrationsfunktionalität, die in den RDEs zur Verfügung stehen. Als Python-basierte Automatisierungsplattform können über Cloudomation über “reine” Infrastrukturautomatisierung der RDE hinausgehend viele weitere Schritte im selben System automatisiert werden – wie zum Beispiel automatisierte Integration Tests auf der RDE.
Jetzt vergleichen:
Fazit
REDs sind Remote-Entwicklungsumgebungen, die lokale Entwicklungsumgebungen ersetzen sollen.
Seit wenigen Jahren gibt es erste Software-Lösungen, die das Bereitstellen von RDEs unterstützen wollen – viele davon sind aktuell aber noch sehr eingeschränkt und bieten etwas weniger Funktionalität als eine lokale IDE.
Es braucht aber mehr als eine IDE, es braucht eine Runtime Umgebung für die zu entwickelnden Applikationen und Automatisierungswerkzeuge, um dort lokalen Build zu ermöglichen. Mit dieser erweiterten Funktionalität wird eine Remote-IDE zu einer RDE. Erst dann haben Entwickler_innen die Werkzeuge bei der Hand, um mit RDEs wirklich produktiv zu werden.
Jetzt den Cloudomation-Newsletter abonnieren
Werden Sie Cloudomation-Insider. Immer am Ende des Monats neue News zum Thema „Remote Development Environments“ und „DevOps“ erhalten.
Grafik: Graphic Art Sangla von Pixabay
