Warum die lokale Entwicklungsumgebung abgelöst werden sollte

Entwickler_innen arbeiten in Entwicklungsumgebungen. Dort schreiben sie Code, Testen und Debuggen. Eine lokale Entwicklungsumgebung beinhaltet u. A. einen Editor (IDE), einen Browser, ein Terminal, eine Datenbank, das Endprodukt, also die Software des Unternehmens, die es zu entwickeln gilt und viele andere Tools. Die Entwicklungsumgebung hat also einen wesentlichen Einfluss, wie produktiv und zufrieden* Entwickler_innen sind.

In der Praxis gibt es allerdings ein Problem: Der lokale Betrieb der zu entwickelnden Software ist aufwändig und die Verwaltung der Abhängigkeiten mühsam und wartungsintensiv. Viel Zeit wird für die Lösung von Problemen innerhalb der Entwicklungsumgebung aufgewendet und nicht mit dem Schreiben von Code für neue Features. Noch dazu hat jede_r Entwickler_in mit ganz individuellen Probleme zu kämpfen. Das geht schnell zu Lasten der Produktivität. Es gibt zwar Lösungsversuche (Container, CI/CD-Pipeline, Standardisierung), diese sind aber nur teilweise zielführend.

In diesem Beitrag beschreiben wir,

warum diese Probleme nicht nur das Entwickler_innen-Team betreffen, sondern sich schnell auf andere Bereiche und das ganze Unternehmen ausweiten,
welche Alternativen es gibt und warum die lokale Entwicklungsumgebung endlich abgelöst werden sollte.

Inhalt

Lokale Entwicklungsumgebung: Die Problemebenen

Um sich bewusst zu werden, welche Herausforderungen lokale Entwicklungsumgebungen mit sich bringen, werden diese auf vier Ebenen aufgesplittet:

Auf die Individualebene (Betreffen die einzelnen Entwickler_innen),
auf die Teamebene (Betreffen das gesamte Team),
auf die Unternehmensebene (Betreffen das Unternehmen) und auf die Umweltebene (Betreffen die Außenwelt des Unternehmens).

Gehen wir die einzelnen Ebenen durch.

Die Individualebene

Immer wieder werden von Entwickler_innen folgende Herausforderungen thematisiert:

Die Einrichtung der Entwicklungsumgebung: Das initiale Einrichten des Laptops dauert lange (tlw. sogar mehreren Wochen), weil unterschiedliche Komponenten und Services installiert werden müssen. Oftmals ist die Dokumentation auch nicht das Gelbe vom Ei und mehrere Mitarbeiter werden für Rückfragen konsultiert.
Kontextwechsel: Wenn an einem anderen Projekt gearbeitet oder auf eine alte Version zurückgestiegen (z.B. fürs Bug-Fixing) wird, müssen manuell die benötigten Packages installiert, die Datenbank neu konfiguriert und andere Tools neu eingerichtet werden.
Updates & Abhängigkeiten: Komponenten verursachen Fehler – aufgrund eines Updates oder aufgrund von veralteten Abhängigkeiten. Das raubt Zeit.
Hardware: Der Laptop stemmt bestimmte Tasks nicht mehr, weil die Rechenleistung oder der RAM nicht ausreicht.
Sicherheit: Ein Laptop mit Unternehmensinfos ist für Angreifer Gold wert. Auf Reisen besteht immer die Gefahr des Verlustes / Diebstahls.

Die Teamebene

Zu neuen Herausforderungen kommt es, wenn es mehrere Entwicklungsteams in Unternehmen gibt:

Nutzung verschiedener Tools: Unterschiedliche Hardware und Betriebssysteme (in unterschiedlichen Versionen) werden verwendet. Für einige Tools benötigt es deshalb Workarounds.
Works on my machine: Durch die unterschiedlichen Konfigurationen funktioniert bei Entwickler_in 1 alles, bei allen anderen aber nicht – klassische “works on my machine” Probleme treten auf.
Zusammenarbeit mit externen Entwickler_innen: Die Zusammenarbeit ist durch die individuellen Probleme schwierig – auch das Onboarding dauert sehr lange und aufwändig.
Dokumentation: Die Wikiseite, in der die Details zum Aufsetzen der Entwicklungsumgebung und für die alltägliche Arbeit enthalten sein sollte, wird nicht oder nur unregelmäßig aktualisiert.
Ressourcen: Entwickler_innen wenden sich an weitere Personen, um individuelle Probleme mit der lokalen Entwicklungsumgebung zu lösen. Es sind also mindestens 2 Personen mit der Problembehebung einer Entwicklungsumgebung beschäftigt und nicht mit der eigentlichen Arbeit.

Die Unternehmensebene

Die vorher erwähnten Probleme führen zu weiteren Herausforderungen. Diesmal auf Unternehmensebene.

Produktivität: Ständige Probleme mit der Entwicklungsumgebung und der mühsame Kontextwechsel verringern die Produktivität. Neue Features und Bugfixes finden nur langsam den Weg zum Kunden. Die Geschäftsführung macht Druck.
Kultur / Motivation: Entwickler_innen sind zunehmend frustriert über die Arbeit. Das spiegelt sich auch früher oder später in öffentlich einsehbaren Unternehmensbewertungen wider.
HR: Die HR-Abteilung sieht ein Bottleneck beim Onboarding von Entwickler_innen. Es dauert einfach zu lange. Zusätzlich muss sich die Abteilung noch stärker mit der Zufriedenheit der Entwickler_innen herumschlagen.
Leak: Wird ein Laptop gestohlen und der Quellcode veröffentlicht, sind alle Systeme in Gefahr, die Reputation ist dahin und die Konkurrenz reibt sich die Hände.

Die Umweltebene

Auch außerhalb des Unternehmens kommt es zu Herausforderungen:

Kunden: Warten lange auf Updates und Bugfixes. Verlieren das Vertrauen in das Unternehmen und suchen im schlimmsten Fall nach einer Alternative.
Sonstiges: Weniger Bewerber, Vertrauensverlust.

Diese Auflistung zeigt: Eine scheinbar kleine Herausforderung, die nur das Entwicklungsteam betrifft, führt zu einem riesigen Problem, um das sich über Abteilungsgrenzen hinweg Gedanken gemacht werden muss.

Die Frage ist – Warum ist die lokale Entwicklungsumgebung am eigenen Laptop noch immer das Mittel der Wahl?

Ist keine Lösung in Sicht?

Das hat praktische Gründe: Denn lokale Entwicklungsumgebungen sind schnell an andere Verhältnisse anpassbar und bieten eine hohe Flexibilität. Unserer Erfahrung nach gibt es aber noch einen anderen Grund: Die Situation wird hingenommen, weil es diese Probleme immer schon gab. Die Frustrationstoleranz ist mittlerweile einfach sehr hoch – “Jeder hat diese Probleme, ist halt so”. Ein weiterer Grund: Bei der Geschäftsführung schlagen diese Probleme noch nicht laut genug auf. Das heißt: Business as usual.

Doch es gibt bereits Tools, auf die Entwickler_innen zurückgreifen können.

Die Alternativen

Virtuelle Maschinen, Docker und Remote Development Environments sind Tools, um den oben erwähnten Problemen zu begegnen.

Momentan wird diesem Problem folgendermaßen begegnet:

Mit Standardisierung (Richtlinien),
Containerisierung und mit Vollautomatisierten CI/CD-Pipelines

Standardisierung über Richtlinien hilft zwar, die Probleme einzudämmen, ist aber auch schwer durchzusetzen. Entwickler_innen müssen Tools einsetzen und ein vom Unternehmen vorgegebenes Betriebssystem verwenden. Das führt oft zu Frustration.

Containerisierung ist ein weiterer Ansatz, mit dem einige Probleme gelöst werden können. Aber auch hier kommt es zu Herausforderungen und neuen Problemen. Mehr dazu in unserem Blogbeitrag: Probleme mit der lokalen Entwicklungsumgebung: Ist Containerisierung die Lösung?

Automatisierte CI/CD-Pipelines werden in der Praxis häufig eingesetzt, um die zu entwickelnde Software nicht mehr lokal ausführen zu müssen. Allerdings wird die Pipeline damit zweckentfremdet. Die Pipeline sollte sich von lokalen Build-Tools unterscheiden und separat im Einsatz sein.

Eine detailiertere Beschreibung der Lösungsansätze finden Sie im Blogbeitrag: Warum wir beschlossen haben, Remote Development Environments (RDEs) zu entwickeln

Eine weitere Alternative, die seit einiger Zeit im Dunstkreis der Softwareentwicklung herumschwirrt, und 2022 so richtig Fahrt aufgenommen hat: Remote Development Environments (RDEs) / Cloud Development Environments (CDEs). Zahlreiche Unternehmen steigen gerade auf RDEs um. Und das lohnt sich: Beobachtet wird, dass das Onboarding verkürzt, sich die Build-Zeiten verbessern und das Troubleshooting abnimmt. Warum? Da RDEs auf Servern laufen, ist die Leistung einfach skalierbar. Jedes beliebige Gerät kann für die tägliche Arbeit verwendet werden. Zusätzlich verbessert sich der Arbeitsprozess: Der Switch von einer Version auf eine andere ist unkompliziert. Es wird einfach die RDE gewechselt, in der das Projekt läuft. Dort ist bereits alles konfiguriert und startklar. Auch der Schutz des Quellcodes verbessert sich: RDEs können Air-Gapped eingerichtet werden, damit der Quellcode und Testdaten nicht am Entwickler_innen-Laptop landen. Zu beachten ist aber, dass je nach Anbieter mit dem Begriff “RDE” etwas anderes gemeint ist. Eine Einführung in das Thema und wie sich die Anbieter unterscheiden, finden Sie in diesem Beitrag “Was sind Remote Development Environments”.

RDEs – Die Zukunft

Noch immer schlagen sich Entwickler_innen tagtäglich mit Problemen herum, die die lokale Entwicklungsumgebung betreffen. Das muss sich ändern. Denn die scheinbar kleine Herausforderung “lokale Entwicklungsumgebung” zieht einen ganzen Rattenschwanz an größeren Problemen mit sich.

Wir sind überzeugt davon, dass RDEs die Zukunft sind. Cloudomation DevStack – unser RDE-Produkt – setzt dem ganzen Drama rund um die lokale Entwicklungsumgebung ein Ende. Legen Sie Konfigurationsparameter für Entwicklungsumgebungen fest, die Ihre Entwickler_innen dann verwenden, um individuell und im Self-Service RDEs zu erstellen. Sofort sind produktionsähnliche Entwicklungsumgebungen verfügbar. Ist das Problem in Ihrem Unternehmen auch schon lange ein Thema? Dann ist Cloudomation DevStack eine Option, die Sie als Lösung in Betracht ziehen sollten.

* https://www.mckinsey.com/industries/technology-media-and-telecommunications/our-insights/developer-velocity-how-software-excellence-fuels-business-performance&sa=D&source=docs&ust=1691659380434514&usg=AOvVaw3Lkb3whTD6Ba2KoyDzFC0Q