Dynamische Entwicklungsumgebungen – was soll das?

In vielen unserer Projekte ist es üblich, dass wir mit mehreren Mitarbeitern an mehreren Entwicklungen gleichzeitig arbeiten. Deswegen passiert es dann öfters, dass zwei oder mehrere Aufgaben parallel entwickelt, aber unabhängig voneinander getestet oder abgenommen werden sollen. Wieso wir uns zur Lösung dieses Problems für dynamische Entwicklungsumgebungen entschieden haben, verraten wir Euch jetzt:

Grundsätzlich erstellen wir pro Aufgabe einen eigenen Branch in Git, wodurch das parallele Testen und Abnehmen kein Problem darstellt. Für viele Projekte besitzen wir allerdings nur ein zentrales Abnahmesystem. Auf dieses Abnahmesystem kann dann immer nur ein Branch nach dem anderen ausgespielt werden. Verzögert sich beispielsweise die Abnahme einer Entwicklung durch Abwesenheit eines Mitarbeiters oder des zuständigen Ansprechpartners beim Kunden, so sind alle weiteren Entwicklungen vorerst blockiert und das gesamte Projekt kommt zum Stillstand. Das sorgt nicht nur für Verzögerungen im Gesamtprojekt, sondern auch für Unzufriedenheit bei unseren Mitarbeitern.

Damit wir also zukünftig mehrere Branches gleichzeitig ausspielen können, mussten mehrere Abnahmesysteme her. Hierzu haben wir bereits auf dem TYPO3Camp Rhein-Ruhr 2017 ein Konzept für dynamischen Entwicklungsumgebungen entwickelt.

Auf Basis von Docker und Kubernetes haben wir uns zunächst einen eigenen Cluster für Docker-Container aufgesetzt.

Die Steuerung der dynamischen Entwicklungsumgebungen übernimmt Gitlab CI. Durch jeden Push eines Branches erzeugt ein Job in der Pipeline von Gitlab CI eine neue Version eines Docker-Images. Das Image für Docker wird speziell nur für den Branch erzeugt und beinhaltet unter anderem alle Artifacts und das Projekt an sich.

Das Starten bzw. Aktualisieren einer Entwicklungsumgebung erfolgt dann via Slack-Befehl oder direkt über Gitlab CI. Löschen wir den Branch, so stoppt in Gitlab CI die Pipeline. Bevor die Pipeline stoppt, wird durch einen Job noch die Entwicklungsumgebung gestoppt und gelöscht.

Der größte Vorteil ist ganz klar, dass wir pro Aufgabe in einem Projekt ein eigenes Abnahmesystem haben. Hierdurch stellt das Testen und Abnehmen von parallelen Aufgaben kein Problem mehr dar. Für Projektleiter und Entwickler entsteht dadurch kein Mehraufwand zum Ausspielen und Testen einer Aufgabe. Besonders in Kundenprojekten, in denen häufig viele Entwicklungen und Teilprojekte gleichzeitig laufen, konnten wir durch die dynamischen Entwicklungsumgebungen den Druck aus dem System nehmen und einen Großteil der vorher notwendigen Absprachen innerhalb der Teilprojekt-Teams eliminieren. Auch der allgemeine Unmut bei "besetzten" Abnahmeumgebungen gehört nun der Vergangenheit an.

Als Nachteil müssen wir hier ganz klar die benötigte Infrastruktur nennen. Je mehr Abnahmesysteme auf dem Cluster laufen, desto mehr Hardware benötigen wir. Entsprechend muss auch die Finanzierung des Clusters gewährleistet sein. Zudem entsteht logischerweise ein gewisser Aufwand, um den Cluster und die darauf laufenden Entwicklungsumgebungen zu konfigurieren und zu verwalten.