Wie ich als DevOps-Engineer mein Team stärke

In der modernen Softwareentwicklung kommen immer mehr und mehr Technologien zum Einsatz. Diese Tools erleichtern die Arbeit und steigern die Produktivität, müssen aber auch eingerichtet, gewartet und an neue Anforderungen angepasst werden. Das wiederum benötigt Zeit und Know-How. Als DevOps-Engineer bringe ich genau dieses Wissen in das Team mit.

Einsetzen konnte ich mein Wissen, als kurzfristig der Auftrag kam, mit einem Software-Projekt in die neue firmenweite Toolchain zu übersiedeln . Die größte Herausforderung? Den laufenden Entwicklungsbetrieb nicht zu stören.  Die Entwickler hatten einen vollen Zeitplan mit neuen Features und Bugfixes, die dringend benötigt wurden. Gleichzeitig konnte der Betrieb der veralteten Toolchain nicht mehr lange aufrechterhalten werden und genau da kam ich ins Spiel. Während sich der Rest des Teams auf dessen Kernkompetenz – das Programmieren, Analysieren  und Testen von Software – konzentrieren konnte, begann ich gleichzeitig neue Server einzurichten und CI/CD-Pipelines zu migrieren. Da ich schon länger in dem Team mitgearbeitet hatte, kannte ich bereits die bestehenden Systeme und deren Konfigurationen, wodurch ich ohne zusätzliche Einarbeitungsphase gleich mit der Arbeit beginnen konnte. Am Ende des Sprints konnten wir im Review nicht nur fertige Features und gefixte Bugs präsentieren, sondern auch die vollständig migrierte Toolchain.

Ein Kollege hat das so zusammengefasst: “War ich froh, dass du dich darum gekümmert hast. Hätten wir uns das auch noch anschauen müssen, wären wir sicher nicht mehr rechtzeitig fertig geworden.”

Jeder kennt es und hat es schon oft erlebt. Man arbeitet konzentriert an einer Sache und wird auf einmal abgelenkt. Sei es eine E-Mail, die beantwortet werden muss, ein Meeting, das ansteht oder ein Telefonat, das dazwischen kommt. Wenden wir uns danach wieder der vorherigen Arbeit zu, brauchen wir wieder etwas Zeit, um ganz bei der Sache zu sein, um konzentriert weiterarbeiten zu können. Das liegt daran, dass unser Gehirn nicht für größere Kontextwechsel optimiert ist. Diese Kontextwechsel finden auch ständig im Alltag der Softwareentwicklung statt. 

Hierzu ein Beispiel: Die Product Ownerin wollte den neuesten Stand der Applikation deployen um dort frisch entwickelte Features anzuschauen. Die dafür vorgesehene Pipeline brach jedoch mit einem kryptischen Fehler ab. Sie informierte das Entwicklungsteam und bat um Hilfe.

Wenn ich mich als Entwickler jetzt darum kümmern würde, dann muss ich zuerst meinen Kontext der Java Entwicklung und den fachlichen Anforderungen an die Software verlassen. Ich wechsle in den Bereich der Pipelines, deren Aufbau ich je nach Komplexität nicht genau kenne und versuche, die fehlerhafte Stelle zu finden. Dabei muss ich die Logs von unterschiedlichen Tools lesen und verstehen können. Zu guter Letzt verbinde ich mich auf den Linux Server mit dem fehlgeschlagenen Deployment und löse dort mit einem Neustart das Problem. Nachdem ich durch die verschiedenen Systeme gegangen bin, wende ich mich wieder der Entwicklung zu, brauche jedoch wieder einige Zeit, bis ich konzentriert weiterarbeiten kann.

In meiner Funktion als DevOps Engineer treffen mich diese Kontextwechsel nicht so drastisch, da die Arbeit mit unterschiedlichen Systemen und Tools mein alltägliches Kerngebiet ist. Ich verlasse meinen Arbeitskontext nicht so stark, da ich mich jeden Tag intensiv mit diesen Technologien auseinandersetze. Auch fällt es mir leichter, mich schnell zurechtzufinden. Durch meine Erfahrung erkenne ich die Zusammenhänge von Fehlermeldungen und weiss wo die Ursache des Problems liegt und kann diese schnell beheben.

Als letztes Beispiel möchte ich aufzeigen, warum gerade die aktive Mitarbeit im Entwicklungsteam wichtig ist und ich nicht ausgelagert in meinem Kämmerchen arbeite. 

Bei einem Gespräch mit einem Analytiker habe ich erfahren, dass er zum wiederholten Male einen ganz spezifischen Datenbestand in der Applikation herrichten muss und ihn das viel Zeit kostet. Die Zeit würde er aber lieber investieren, um an der eigentlichen Aufgabe weiterarbeiten zu können. Bei mir läuteten sofort die Alarmglocken: “Sich wiederholende Schritte, viel Zeit, die verloren geht?” Das klingt nach Automatisierung! Also setzte ich mich daran und baute eine Pipeline, in der man einen Server auswählen kann, dessen Datenbestand man sich speichern möchte. Genauso kann man mit der Pipeline einen gesicherten Datenbestand auf Knopfdruck wieder einspielen. Als ich die Pipeline her zeigte, war ein Lächeln auf dem Gesicht zu sehen: “Ich wusste gar nicht, dass das so einfach möglich ist. Das spart ja richtig Zeit, Danke!” 

Mittlerweile sind weitere Erweiterungen hinzugekommen, wie etwa das Aufsetzen einer neuen Version der Applikation, bevor die Daten eingespielt werden. Die Pipeline wird zudem vom Entwickler-, Analyse- und Test Team verwendet. Hätte ich nicht im Team mitgearbeitet, wüsste ich von den Problemen nichts und der Analytiker hätte bis heute weiter viele Stunden seiner Zeit verloren mit dem Einrichten von Datenbeständen.

Anhand der Beispiele sieht man, dass ich als DevOps-Engineer durch meine aktive Mitarbeit im Entwicklerteam Prozesse beschleunigen kann. Durch die Übernahme technischer Themen, die nicht in den Kernbereich der Entwickler und Entwicklerinnen fallen, ermögliche ich es dem Team, sich auf seine Hauptaufgaben zu konzentrieren. Dadurch gibt es weniger Verzögerungen und Probleme können schneller gelöst werden.