5 Vorteile von Remote Development Environments

  • Veröffentlicht

Softwareentwickler_innen arbeiten normalerweise in ihrer lokalen Entwicklungsumgebung. Da jede lokale Entwicklungsumgebung anders ist, treten jedoch sehr individuelle Probleme auf, deren Lösung zeitaufwändig und schwierig ist. Mit Remote Development Environments wird die Zeit, die Entwickler_innen mit der Wartung ihrer lokalen Entwicklungsumgebung verbringen, auf null gesenkt. Welche Vorteile gibt es noch?

Remote Development Environment - Was bedeutet das eigentlich?

Kurz und knapp: Remote Development Environments (RDEs) sind Remote-Entwicklungsumgebungen, die lokale Umgebungen ersetzen sollen.

Um das zu ermöglichen, müssen in RDEs alle Tools zur Verfügung stehen, die zur Softwareentwicklung notwendig sind – inklusive der zu entwickelnden Applikation, die in der RDE betrieben werden kann und auf die Entwickler_innen vollen Zugriff haben.

Achtung: Andere RDE Anbieter haben meist ein deutlich reduziertes Verständnis und bieten nur ein Subset an Funktionalität an, wie z.B. eine Browser-basierte IDE oder remote-fähige IDE mit einem remote laufenden Backend. Diese Angebote unterstützen im Allgemeinen nicht den Betrieb der vollen zu entwickelnden Applikation in der RDE und auch deutlich weniger Zugriff auf und weniger Tooling in RDEs als in Cloudomation RDEs zur Verfügung steht. 

Im Artikel “Was sind Remote Development Environments” haben wir alle Details dazu beschrieben.

5 Vorteile von Remote Development Environments

#1 Zeitersparnis

Elijah Bate von theoptimisedweb.com schreibt: “Das Einrichten neuer Entwicklungsumgebungen oder der Versuch, den lokalen Rechner für verschiedene Projekte zu aktualisieren, wenn die Konfigurationen unterschiedlich sind, ist wirklich ätzend. Die Zeit, die andere Entwickler und ich damit verbracht haben, Probleme mit der Nodejs-Version zu debuggen, verschiedene SDKs zu installieren und zu deinstallieren und Umgebungsvariablen und Secrets zu finden und einzurichten, ist einfach wahnsinnig.

Elijah Bate ist mit diesem Problem nicht alleine. Die Einrichtung und Wartung der persönlichen Entwicklungsumgebung wird als eine der unangenehmsten Aufgaben von Entwickler_innen wahrgenommen. 

Mehrere Stunden pro Monat werden oft mit Fehlerbehebung verbracht. Da jede lokale Entwicklungsumgebung leicht anders ist als die der Kolleg_innen, hat jede_r Entwickler_in mit ganz eigenen Problemen zu kämpfen.

Neben IDE-Tool und Source Control, was meist schnell aufgesetzt ist, sind vielerlei Abhängigkeiten einzurichten und aktuell zu halten, Tools für lokalen Build zum Laufen zu bringen und meist am herausforderndsten: Die zu entwickelnde Software selbst lokal zu betreiben. Dabei kommen oft im Unternehmen selbst entwickelte Tools und Skripte zum Einsatz, die fehleranfällig und schwer zu bedienen sind. 

RDEs lösen dieses Problem. Die Zeit für Problembehebung sinkt auf Null. Verschiedene Versionen der zu entwickelnden Software können ganz einfach parallel bearbeitet werden, in separaten RDEs. Ein Wechsel des Geräts ist außerdem einfacher möglich. Zusätzlich kann Softwareentwicklung auf fast allen Endgeräten stattfinden, auch wenn diese wenig leistungsstark sind.

#2 Standardisierung

Ein Problem lokaler Entwicklungsumgebungen ist, dass jede anders ist.

Selbst mit strikten Geräte- und Software-Richtlinien können die möglichen Störfaktoren zwar eingeschränkt, aber nie ganz aus der Welt geschafft werden. Es treten trotzdem individuelle Probleme mit lokalen Entwicklungsumgebungen auf.

Besonders frustrierend ist das, wenn man bedenkt, wie aufwändig es ist, Standardisierungs-Richtlinien zu entwickeln und kontinuierlich durchzusetzen und wie viel Widerstand und Frust damit häufig bei Entwickler_innen erzeugt wird, die auf liebgewonnen Tools verzichten und stattdessen mit Software arbeiten müssen, die sie nicht mögen.

Wie wäre es, wenn Entwickler_innen auf Knopfdruck vollständig standardisierte Entwicklungsumgebungen zur Verfügung hätten, die jedes mal neu erstellt werden und zu 100% exakt den Richtlinien entsprechen? 

Und daneben Entwickler_innen ganz freie Hand gegeben werden kann, was sie lokal für Betriebssystem, Browser oder sonstige Tools verwenden? Genau das machen RDEs möglich.

Der größte Vorteil: Standardisierte RDEs werden natürlich so definiert, dass sie der Produktionsumgebung der zu entwickelnden Software so nahe wie möglich kommen.

Aufgrund der Einschränkungen lokaler Umgebungen vs. der Server-Umgebung der RDEs kommen RDEs der Produktivumgebung deutlich näher (z.B. wird auch der Betrieb eines Kubernetes-Clusters auf einer RDE plötzlich machbar, was lokal zu sehr viel Kopfschmerz führen kann). Damit wird auch das “works on my machine” Problem reduziert.

Und das bei gleichzeitig deutlich höherer Developer Experience – also angenehmerer und erfreulicherer Arbeitsweise für Entwickler_innen.

Mehr dazu: Cloudomation DevStack – Das Remote Development Environments Produkt

#3 Rechenintensive Ressourcen auslagern

Joel Spolsky schreibt: “Erstklassige Entwicklungsteams quälen ihre Programmierer nicht. Selbst kleine Frustrationen, die durch die Verwendung unzureichender Werkzeuge verursacht werden, summieren sich und machen die Programmierer mürrisch und unglücklich. Und ein mürrischer Programmierer ist ein unproduktiver Programmierer.

Entwicklung von Software bedeutet, dass rechenintensive Arbeiten durchgeführt werden müssen, wie beispielsweise Kompilieren, Testen und Ausführen der Software.

Das bedeutet: Frustration bei Entwickler_innen, wenn der RAM aufgrund eines Tools fast in Flammen aufgeht und auf die Fertigstellung von Tests etc. gewartet werden muss. Und: Frustration beim Management aufgrund der Kosten für die Bereitstellung von entsprechendem Equipment.

Da mit RDEs leistungsintensive Prozesse übernommen werden und auf einem Remote-Server stattfinden, kann die Auswahl des Arbeitsgeräts günstiger ausfallen und die Kosten für Unternehmen senken.

Entwickler_innen haben in den RDEs dennoch alle – und noch mehr – Ressourcen zur Verfügung, die sie für komfortable Entwicklungsarbeit brauchen.

Aufgrund der Skalierbarkeit von RDEs sind diese meist sogar deutlich performanter als selbst sehr mächtige Laptops.

Die Zeiten sind vorbei, in denen Entwickler_innen ewig auf das Fertigwerden des lokalen Builds warten (weil der Laptop daneben nichts schafft und der Build trotzdem lange braucht).

Die Produktivität Ihres IT-Teams mit Remote Development Environments auf das nächste Level heben

In diesem Whitepaper erfahren Sie, wie Remote Development Environments (RDEs) helfen, den Aufwand für die Wartung der lokalen Entwicklungsumgebung zu reduzieren und die Produktivität Ihres IT-Teams zu erhöhen.

Jetzt herunterladen

#4 Produktivität

Alle Entwickler_innen kennen es: In der lokalen Entwicklungsumgebung Branch zu wechseln oder gar auf eine alte Version der Software zurücksteigen, um einen Bug zu fixen oder zu überprüfen, ist mühsam.

Alles muss zusammenpassen: Alle Abhängigkeiten müssen in der richtigen Version vorhanden sein, alle Komponenten der Software müssen miteinander funktionieren – und wer weiß nochmal genau, welche Versionen kompatibel waren?

Nach dem Bug Fix geht das ganze dann wieder in Revers: den eigenen aktuellsten Feature Branch wieder pullen, Abhängigkeiten updaten, und hoffen, dass der Kunde, der noch die alte Version nutzt, nicht so bald wieder einen Bug findet. Die in der neuen Version ohnehin alle bereits behoben sind. 

Lösung? Klar, alle Kunden dazu zwingen, immer die letzte Version zu nutzen. Leider ist das in der Realität oft nicht möglich. 

Und auch ohne Kunden-Bugfixes in alten Versionen ist das Wechseln von Branches oft notwendig, es ist ein Teil normaler Entwicklungsarbeit.

Die Lösung kann daher nicht sein, Branch-Switching obsolet zu machen. Eine schönere Lösung: RDEs.

Diese stehen in allen benötigten Versionen fix und fertig zur Verfügung. RDEs können bei Bedarf nicht nur für Major-Versionen, sondern sogar für spezifische Commit-Hashes einzelner Branches erstellt werden. Jede_r Entwickler_in kann mehrere davon parallel betreiben. Damit wird das Arbeiten in unterschiedlichen Branches plötzlich zum Kinderspiel.

Das erhöht nicht nur die Produktivität und senkt den Frust, sondern führt auch zu deutlich besserer Unterstützung von Kunden. Denn wenn es einfach geht, hilft man doch gleich viel lieber.

#5 Sicherheit von Source Code und Daten

In Zeiten der Remote-Arbeit wissen Vorgesetzte manchmal gar nicht so genau, wo sich ihre Entwickler_innen gerade befinden.

Zusammenarbeit mit Freelancern in der ganzen Welt wird immer normaler. Und damit wird das Thema der Sicherheit von Source Code und Daten immer dringender

Denn was passiert, wenn der Laptop im Taxi in Delhi liegen bleibt? Oder die Kolleg_innen in den USA im Co-Working-Space kein absperrbares eigenes Büro haben, sondern ihr Arbeitsgerät über Nacht einfach offen liegen lassen?

Ist das Endgerät einmal verloren, kann zwar der Zugriff auf Remote-Sourcen gesperrt werden – was sich am Laptop befindet, ist jedoch für immer verloren. 

Eine ganz eigene Kopfweh-Kategorie: Zugriff auf personenbezogene Daten, die zum Testen der Software notwendig sind. Wie ist das am Besten zu regeln, rechtlich und auch praktisch, wenn das eigene Team auf der ganzen Welt verstreut ist?

Maßnahmen wie Verschlüsselung von Festplatten, Richtlinien zur Nutzung von vertrauenswürdigen Netzwerken, Deaktivierung von USB Ports, Arbeiten über VPNs – viele mögliche Lösungsansätze existieren. Alle sind problematisch, denn jeder einzelne involviert signifikanten Aufwand, ist schwer zu enforcen und löst das Problem dennoch nur zum Teil. Was tun?

Sie ahnen die Antwort: Cloudomation RDEs können vollständig air-gapped eingerichtet werden, sodass Source Code nie lokal am Rechner der Entwickler_innen landet. Testdaten können in RDEs genutzt, aber so abgeschirmt werden, dass Entwickler_innen keinen direkten Zugriff haben. 

Für Entwickler_innen ist die Arbeit in der RDE komfortabel, damit existieren auch keine Anreize für Missbrauch, der häufig im Dienste der Produktivität und mit besten Intentionen stattfindet. Und da Source Code und Daten gar nie lokal abgelegt werden, ist das Risiko bei Verlust oder Diebstahl des Endgerätes gleich null. 

Fazit

  • RDEs helfen, wertvolle Zeit zu sparen: Bei der Einrichtung der Entwicklungsumgebung und in weiterer Folge beim Troubleshooting.
  • RDEs führen zu einer Standardisierung von Entwicklungsumgebungen. Dadurch wird die Fehlerbehebung einfacher, Unternehmensrichtlinien werden zu 100 % erfüllt und Entwickler können trotzdem ihre Lieblings-Tools verwenden. Außerdem kommen sie der Produktionsumgebung so nahe wie möglich.
  • Rechenintensive Ressourcen werden ausgelagert. Die Entwicklungsarbeit kann damit auf fast allen Geräten stattfinden.
  • Die Produktivität steigt, weil bei einem Branch-Wechsel nur die dafür eingerichtete RDE aufgerufen werden muss.
  • Sicherheit: Mit RDEs landet der Source Code nie am Rechner.
  • RDEs helfen, aktuelle Herausforderungen in der Softwareentwicklung zu lösen.

Jetzt den Cloudomation-Newsletter abonnieren

Werden Sie Cloudomation-Insider. Immer am Ende des Monats neue News zum Thema „Remote Development Environments“ und „DevOps“ erhalten. 




    Johannes Ebner

    Marketing Manager