O-Neko - Deployments von Entwicklungsständen mit Docker und Kubernetes

26.09.2019

Diese Woche stellen wir Euch eine neue Lösung vor, die wir, das Team Weasel, in einer Vielzahl von Lab-Days innerhalb der letzten 1,5 Jahre entwickelt haben. Wer den Lesegenuss in Häppchen schätzt, kann unsere „O-Neko-Story“ als Fünfteiler lesen – zum Beispiel pro Wochentag einen Beitrag hier im Blog. Freunde langer Texte können den ganzen Artikel auch direkt hintereinander lesen. Und wer es eilig hat und trotzdem alles wissen möchte: Im tl;dr am Ende haben wir eine Zusammenfassung.

Der Kampf um die Produktivität

Montagvormittag, am 18. Dezember 2017 um halb 11: Wie in jeder zweiten Woche kurz vor Sprintbeginn trafen wir uns im Team zu unserer Retro, um den vergangenen Sprint Revue passieren zu lassen.  

Zu dieser Zeit hatten wir sehr intensiv an vielen neuen Features und Verbesserungen für den Sophora MobileClient gearbeitet. Um unsere Arbeit gut zu parallelisieren, hatten wir für jede Aufgabe einen eigenen Entwicklungs-Branch im Code genutzt. Obwohl dieses Vorgehen mittlerweile ein Standard in der Industrie ist, war es bei uns bis dahin nicht üblich gewesen und in seiner konsequenten Umsetzung neu für alle Projektbeteiligten.

Während Branches uns Entwicklern die Arbeit erleichterten, sorgten sie zu der Zeit teilweise für Frust bei unseren Testern und Projektmanagern. Der Grund dafür waren die Unzulänglichkeiten unserer statischen Testinfrastruktur, in der wir für jede weiterentwickelte Major-Version sowie für die kommende Version einen Testserver haben. Jeder dieser Server besteht aus Sophora-Servern, einer Demoausspielung und den meisten unserer Tools, also auch dem MobileClient. Erst wenige Wochen vorher hatten wir Sophora 2.5 released und verfügten somit über Testserver für die Versionen 2.5, 2.4, 2.3 und die nächste Version 2.6 (die wir etwa ein Jahr später in 3.0 umbenennen würden).

Zu Erläuterung: Die Entwicklungsstände unserer Software, die automatisch auf den Testservern installiert werden, ermitteln sich aus der Haupt-Codebasis jedes Projekts. Entwicklungsstände für Features, die auf eigenen Branches entwickelt wurden, wurden somit auf keinem Testserver installiert. Für uns Entwickler, die eine eingerichtete Entwicklungsumgebung auf dem eigenen Computer hatten, war das kein Problem, da jeder Entwicklungsstand im Handumdrehen kompiliert und gestartet werden konnte. Wollte aber ein Projektmanager kontrollieren, wie weit ein Feature bereits funktionierte oder wie das UI einer Entwicklung aussah, musste er entweder auf das Wohlwollen und Präsentationstalent eines Entwicklers hoffen oder versuchen, eine eigene Entwicklungsumgebung einzurichten.

Das Ganze entwickelte sich zu einer Diskussion zwischen Entwicklern und Projektmanagern, bei der wir als Entwickler natürlich nicht darauf verzichten wollten, Branches zu nutzen, weil sie uns produktiver machten. Auf der anderen Seite wollten die Projektmanager Features unabhängig von uns möglichst schnell auf den Testservern sehen, um selber produktiv zu sein. Es ging also darum, die jeweiligen Bedürfnisse nach Produktivität gegeneinander abzuwägen, denn sowohl Entwickler als auch Projektmanager hatten plausible Argumente für ihre jeweilige Haltung.

So begannen wir, während unserer Retrospektiven nach einem neuen Weg zu suchen. Die Messlatte war hoch, denn es musste eine Lösung gefunden werden, mit der alle glücklich werden konnten.

Der Kampf um die beste Lösung

Die Inspiration für die problemlösende Idee kam durch Zufall von einem unserer Kunden. Um Weiterentwicklungen an seiner Website testen zu können (die ebenfalls auf Branches entwickelt wurde), ist dort ein kleines selbstgebasteltes Programm im Einsatz, welches mithilfe von Docker-Containern auf einem Server die Ausspielungen zu allen Branches bereitstellt. Damit das funktioniert, ist ein Konglomerat an unterschiedlichsten Tools notwendig. Weil die Container ausschließlich auf einer einzigen, dedizierten Maschine ausgeführt werden, ist diese so intensiv mit Arbeitsspeicher und Rechenleistung ausgestattet, wie Muskeln in einem Fitnessstudio zu finden sind: Übertrieben viel.

An dieser Stelle sollen nicht alle Details der Vorgänge erläutert werden. Aber diese Lösung umfasst eine selbstgebastelte, puristische Weboberfläche, die es ermöglicht, rudimentäre Einstellungen an der Ausspielung vorzunehmen (Produktiv- oder Testsystem usw.) und die Container ggf. zu stoppen. Zu diesem Programm ist jedoch anzumerken, dass es sehr spezifisch für die zugehörige Website ist und daher nicht ohne weiteres für andere Projekte, wie den Sophora MobileClient, benutzt werden kann.

Wollte man eine analoge Lösung, müsste man also selbst ein entsprechendes Projekt aufsetzen. Für uns klang das nach einem gangbaren Weg. Mit erfinderischem Leichtsinn und überzeugter Naivität traten wir also während der besagten Retrospektive an das Projektmanagement-Team heran und erläuterten unsere Idee, eine Anwendung nach diesem Vorbild zu schaffen, die die Stände der Software aus Entwicklungsbranches ausführt, sodass alle jederzeit Zugriff darauf haben.

Die Idee kam gut an, bis auf ein kleines Detail: Die Entwicklung war mit Kosten verbunden. Außerdem hatten wir bereits viele Projekte mit Terminfristen eingeplant.

Bei uns machte sich leichtes Unverständnis breit: Wie sollten wir ein Problem lösen, ohne dass es Zeit und Geld kosten würde? Glücklicherweise waren unser Erfindergeist und Pragmatismus noch nicht ganz am Ende, so dass wir inmitten dieser schwarz-weiß-Diskussion eine kleine Grauzone entdeckten und uns zunutze machten: Bei subshell dürfen wir pro Person und Sprint einen Tag als sogenannten Lab-Day nutzen und an diesem Tag (oder eben 8 Stunden verteilt über den gesamten Sprint) an Projekten arbeiten, die nicht regulär auf dem Projektplan stehen, sondern beispielsweise dazu dienen, uns weiterzubilden, Wunsch-Funktionen in unsere Software einzubauen oder neue Technologien in Verbindung mit Sophora zu evaluieren. Beim Team Weasel herrschte schnell Konsens, dass wir unsere eigene Branch-Ausspielung als Lab-Day-Projekt umsetzen wollten.

Rückblickend hatte die Deklaration unserer Idee als Lab-Day Projekt sogar viele Vorteile: Keiner konnte uns sagen, was und wie wir es machen sollen, was es können oder wie es aussehen und heißen musste. Diese plötzliche Anarchie spiegelte sich dann auch direkt in unserer ersten Entscheidung wider: Wir legten fest, wie unser neues Haustier heißen würde.

Weiterlesen in Teil 2: „Die Taufe des Kindes

Weasel O-Neko

Team Weasel