Softwareentwicklung im Blindflug: 3 Konsequenzen, eine Lösung

Wie in diesem Blogpost beschrieben ist ein häufiges Problem beim Entwickeln einer Multi-Komponenten-Software, dass es zunehmend schwieriger wird, die gesamte Software als Teil einer lokalen Entwicklungsumgebung lokal auszuführen. Die Konsequenz ist, dass eine wachsende Anzahl an Entwickler_innen daran gewohnt werden „blind“ zu arbeiten und Code-Änderungen direkt auf Staging pushen, ohne die Änderungen lokal zu verifizieren. Das hat drei Konsequenzen:

Langsame oder nicht vorhandene Feedbackschleifen für Entwickler_innen
Qualitätsprobleme
Gesteigerte Abhängigkeit von Reparaturmechanismen

Sehen wir uns diese Herausforderungen im Detail an.

Langsame oder nicht vorhandene Feedbackschleifen

Feedbackschleifen für Entwickler_innen sind langsam oder fehlen komplett. Entwickler_innen bekommen nur für Unit-Tests sofort Ergebnisse. Integrations-Tests, Smoke-Tests, Performance-Tests und andere Tests laufen remote und sind, abhängig vom Setup, oft Teil von Massenänderungen aller Entwickler_innen. Entwickler_innen bekommen entweder sehr spät Feedback, dass eine Änderung problematisch war, oder sie bekommen nie ein spezifisches Feedback, das ihre Code-Änderung betrifft. Das führt zu langsameren Learnings und teurem Bug-Fixing. Zusätzlich ist es wahrscheinlich, dass Entwickler_innen größere Änderungen auf einmal pushen.

Wenn es Entwickler_innen möglich ist, die Software lokal zu builden und das schnell funktioniert, sieht der typische Workflow anders aus. Viele kleine Änderungen werden vorgenommen und mehrmals Builds gestartet, um zu verifizieren, dass die Änderungen funktionieren. Kommt es dann zum Commit (z. B. auf Staging) und ein Ticket (oder Feature) abgeschlossen ist, wissen Entwickler_innen normalerweise sehr gut, dass die Änderungen funktionieren und haben wahrscheinlich schon einige Bugs entfernt. Zusätzlich macht es dieser Workflow möglich, schnell und einfach “zu lernen”, da ständig Änderungen durchgeführt werden und lokal nachvollzogen werden kann, was die Änderungen bewirken.

Wenn kein lokaler Build möglich ist, schließen Entwickler_innen ein Ticket und führen einen größeren Commit ins Repository durch. Dort wird ein Build gemacht und Tests ausgeführt. Wenn es dann aber Probleme gibt (und es gibt immer welche: es ist unmöglich, perfekten Code zu schreiben), müssen Entwickler_innen einen größeren Teil an Code durchsehen, um das Problem zu lösen. Zusätzlich gibt es weniger Möglichkeiten, über das Verhalten des Codes zu lernen. Das ist vor allem bei Juniors bedenklich, die es dadurch viel schwerer haben, etwas über die Software zu lernen. Sie lesen und schreiben Code, haben aber nicht die Möglichkeit, die Änderungen sofort in ihrer eigenen lokalen Umgebung auszuprobieren.

Qualitätsprobleme

Eine direkte Konsequenz der Unmöglichkeit, Änderungen lokal zu verifizieren: Mehr Bugs werden auf Staging und noch viel mehr in Production gelangen. Je früher im Software Development Lifecycle ein Bug gefunden wird, desto schneller und günstiger ist er zu fixen. Wenn die erste Phase der Verifizierung in der lokalen Entwicklungsumgebung entfernt wird, werden Bugs später auftauchen und sind schwieriger und kostenintensiver zu beheben.

Gesteigerte Abhängigkeit von Reparaturmechanismen

Die nächste unmittelbare Konsequenz ist, dass Softwareunternehmen zunehmend in die Optimierung ihrer CI/CD-Pipelines und den Aufbau automatisierter Reparaturmechanismen wie automatisierte Rollbacks, gestaffelte Releases sowie immer höhere Investitionen in automatisierte Tests investieren müssen

All das sind gute Sachen, die man haben sollte. Sie sind aber Mechanismen, die dabei helfen, Probleme erst relativ spät im SDLC zu erkennen und zu beheben. Wenn einmal ein Bug Production erreicht hat und ein so schweres Problem macht, dass ein Rollback durchgeführt werden muss, dann ist es sinnvoll, wenn der Rollback automatisiert passiert. Ein Rollback ist aber der teuerste Lösung für ein Problem. Der Bug selbst muss noch immer behoben werden. Der Rollback und andere zusätzliche Kosten wie Ausfälle in Production, Strafen aufgrund von SLA-Breaches und verlorenes Vertrauen sind alles zusätzliche Kosten, die dazu kommen.

Dies hängt damit zusammen, dass Bugs immer teurer werden, je später im SDLC sie entdeckt werden. In der ersten Validierungsphase auf dem Laptop von Entwickler_innen werden in der Regel die meisten Bugs identifiziert: Bugs, für die nie ein Ticket erstellt wird, weil sie von Entwickler_innen behoben werden, bevor sie überhaupt in ein gemeinsames Repository übertragen werden. Wird diese erste Validierungsstufe abgeschafft, erhöht sich die Anzahl der Fehler, die alle folgenden Schritte des SDLC durchlaufen, wodurch die Abhängigkeit von kostspieligen Reparaturmechanismen steigt.

Lösung: Unterstützung ihrer Entwickler_innen und Entwicklern mit Remote Development Environments (RDEs)

Wie in dem oben erwähnten Artikel beschrieben wird, gibt es eine Lösung, wie Entwickler_innen dabei unterstützt werden können, lokal einen Build auszuführen, auch, wenn die Software zu komplex ist, um diese lokal auszuführen: Entwickler_innen können nur einen oder zwei (Micro-) Services lokal builden (Services, an denen sie arbeiten) und verbinden sich zu einem Shared Remote Development Cluster, wo die anderen Services laufen.

Es gibt aber ein paar Voraussetzungen und Herausforderungen, um das zu tun. Die Herausforderungen können auf die gleiche Weise reduziert werden, wie ein Großteil der Komplexität im SDLC reduziert wird: durch Automatisierung. Cloudomation DevStack ist ein Tool, dass eine Automatisierung für das Deployment von RDEs anbietet, die ein (kleines) ausgewähltes Set von Diensten in der RDE ausführen – Dienste, an denen die Entwickler_innen gerade arbeiten – und sich mit anderen Diensten in einem gemeinsamen Entwicklungscluster verbinden. Das ermöglicht Entwickler_innen, uncommitteten Code innerhalb der RDE auf die gleiche Weise zu builden und zu testen, wie sie es lokal tun würden.

DevStack:

Deployed eine RDE, basieren auf den Anforderungen der Entwickler_innen. Entwickler_innen wählen aus, welche Komponenten und in welcher Version sie diese brauchen. Dann werden
dynamisch Konfigurationsdateien erstellt, um die Komponenten der RDE mit einem Shared Dev Cluster zu verbinden,
stellt sicher, dass die Komponenten auf der RDE eine Verbindung zum richtigen Remote Cluster oder zu den richtigen Remote-Komponenten herstellen und deployed oder startet optional Remote-Komponenten oder Cluster, wenn sie nicht verfügbar sind, und
stellt Entwickler_innen all dies in einer einfachen Webschnittstelle und CLI zur Verfügung.

Warum eine RDE? Warum nicht 1-2 Dienste lokal deployen?

Das größte Problem bei der Automatisierung von lokalen Deployments ist die große Variabilität der lokalen Entwicklungsumgebungen: Vom Betriebssystem bis hin zu bestimmten Library-Versionen, die das lokale Deployment beeinflussen können. Es ist nicht machbar, lokale Deployments zu automatisieren, die alle möglichen Variationen berücksichtigen. Das ist der Grund, warum sich Entwickler_innen mit dem lokalen Deployment sehr schwer tun, selbst wenn die Software im Prinzip lokal ausgeführt werden kann: Selbst wenn viel investiert wurde, um lokale Build-Skripte bereitzustellen, sind immer wieder manuelle Schritte erforderlich. Entwickler_innen müssen aber in der Lage sein, Fehler zu lösen, die spezifisch für ihr Setup sind.

Remote Environments sind standardisiert und viel einfacher zu automatisieren.

Ein kleineres Problem ist, dass die lokalen Rechenressourcen begrenzt sind. Selbst wenn nur ein oder zwei Dienste als Teil der Entwicklungsumgebung deployed werden, kann dies zu einer schlechten Leistung führen.

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 herunterladen

Fazit

Durch die Möglichkeit, ihre Software vor Ort zu entwickeln, erhalten Entwickler_innen die Gelegenheit,

Zu lernen und zu experimentieren,
Fehler frühzeitig zu erkennen und zu beheben,

was wiederum

die Kosten für die Behebung von Fehlern erheblich reduziert
und die Produktivität der Entwickler_innen erhöht.

Software mit vielen (Mikro-)Diensten ist oft zu anspruchsvoll, um lokal ausgeführt zu werden. Damit Entwickler_innen trotzdem schnell iterieren und ihre Codeänderungen mit lokalen Builds und Tests validieren können, können sie nur die Dienste deployen, an denen sie gerade lokal arbeiten und sich mit anderen Diensten auf einem gemeinsamen Entwicklungscluster verbinden. In diesem Blogbeitrag beschreibe ich die Voraussetzungen und Herausforderungen einer solchen Einrichtung.

Um eine solche Einrichtung für eine große Anzahl von Entwickler_innen nutzbar zu machen, kann Automatisierung helfen. Damit wird die Komplexität reduziert. Cloudomation DevStack ist ein Tool, das Automatisierungsfunktionen und Templates für das Deployment von Remote Development Environments (RDEs, gleichbedeutend mit CDEs / Cloud Development Environments) bietet. Die RDE enthält eine kleine Teilmenge von Diensten, die Entwickler_innen auswählen. Die Verbindung zu anderen Diensten in einem Shared Development Cluster wird automatisiert durchgeführt. Die RDE enthält alle Tools, die Entwickler_innen benötigen, um wie lokal arbeiten zu können.