DevOps. Ein neues Schlagwort am Softwarehimmel das viele Unternehmen beschäftigt - und das zu Recht! Der Ansatz lässt Fehler so früh erkennen wie keine andere Methode und reduziert dadurch die Gesamtdurchlaufzeit durch effiziente und rasche Fehlerbehebung. Aber was ist das eigentlich? Und wie lässt es sich in embedded Projekten Einsetzen?
Der Begriff DevOps setzt sich simpler Weise aus den Begriffen Development und Operations zusammen, unterstützt von automatisierten Qualitätssicherungsprozessen. Aha! Operations – gemeint ist die technische Betriebsabteilung.
Betrachten wir mal einmal wie ein typisches Projekt in der Regel abläuft: Als Projektleiter steht man ganz am Anfang des Projekts vor der Entscheidung, welche Ressourcen eingesetzt werden sollen. Schnell ist einem klar, dass unterschiedlichste Rollen in einem Entwicklungsprojekt benötigt werden, um es über die Ziellinie zu schaffen. Mit dem festen Willen, die Anforderungen der Stakeholder zu erfüllen, setzen wir unser Projekt auf. Welche Rollen brauchen wir also für unser embedded Projekt? Üblicherweise läuft es auf die folgenden Rollen hinaus:
- Projektmanager als Koordinator
- Requirements Engineer
- Software Architect
- Development Engineer
- Test Engineer
Sehr gut. Dann hätten wir also alle. Oder?
An dieser Stelle bringt der DevOps-Ansatz eine neue Rolle mit ins Spiel: Genau: den Operations-Engineer aus der oben genannten Fachabteilung
Sicherlich, irgendwer muss ja das Ding letztendlich zum Laufen bringen und am Leben erhalten. Aber müssen sie gleich im Kernteam dabei sein? Nein, oder? Sie produzieren ja schließlich nur getestete und abgenommene Software, wozu sie jetzt schon belästigen? Nach meiner Erfahrung ist es jedoch oftmals so: Das Projekt ist „fast fertig“ und auf einmal trudeln jede Menge Änderungswünsche aus den operativen Fachabteilungen hinein, und alle wundern sich wie das mit der „schlechten Kommunikation“ passieren konnte.
Natürlich muss der Operations-Engineer nicht bei jedem Termin dabei sein, genauso wenig wie die Entwickler oder Tester oder in weiterer Folge auch das Anforderungsmanagement. Was ich sagen will: Der Operations-Engineer hat auch während der Entwicklungsphase eine wichtige Aufgabe und trägt entscheidend zum Projekterfolg bei.
Was hat das jetzt genau mit DevOps zu tun? DevOps geht noch einen Schritt weiter. Im Laufe meiner Projekte war es meistens so, dass der Projektleiter mit dem Software Architekten die betriebliche Seite abfängt. Der Projektleiter auf organisatorischer, sowie terminlicher Ebene, und der Architekt auf technischer Ebene. Sie bilden also eine Schnittstelle zwischen der Entwicklung und dem Betrieb. Sobald Fragen auftauchen wenden sich die Entwickler an diese Personen und nicht direkt an den Betrieb. Der Mittelsmann wendet sich danach an technische Betriebsabteilung. Werden Fehler im Feld gefunden geht es postwendend wieder über dieselbe Schiene zurück. So wie immer. Das Stille-Post Prinzip.
Die Fragen, die sich nun aufdrängen lauten: „Wieso benötigt es überhaupt eine solche Schnittstelle? Wenn Fehler auftreten, dann muss doch der Betrieb die Fehlermeldung direkt an die Entwickler zurückspielen? Sollte nicht die Entwicklung näher mit dem Betrieb zusammenarbeiten?“ Diesmal ist die Antwort auf alle Fragen recht einfach: Ja, natürlich.
Viele Firmen haben genau das oben angeführte Verbesserungspotential erkannt, und versucht mit diversen Tools bzw. Toolchains die Zusammenarbeit zwischen Entwicklung und Operations zu stärken. Was benötigt man dafür? Der Operations Engineer am liebsten ein Produkt – und das ist irgendwie doof, denn wir haben ja noch gar keines. Aber benötigt er wirklich ein fertiges Produkt? Kann man das Produkt nicht nach Teilfunktionen mit entwickeln und die gewonnen Erkenntnisse in die Weiterentwicklung mit einfließen lassen? Ja, das geht. Mit gewissen Einschränkung auch im embedded Bereich – hier liegen die Beschränkungen der Agilität in der Hardware, die sich in der Praxis nicht immer beliebig anpassen lässt, aber erfahrungsgemäß steckt die Funktionalität in der Hauptsache ja in der Software.
Was wir also benötigen sind häufige und kontinuierlich weiterentwickelte Softwarelieferungen. Es gibt keine „Hard Cuts“ mehr, alles geht parallel nebeneinander. Der Schlüssel hierzu ist eine hohe Automatisierung während der Entwicklung für Test, Integration und das Deployment. Das ist die Vorausetzung für den Aufbau einer Continuous Delivery Pipeline. In voller Ausbaustufe werden Änderungen, beginnend vom Check-In, automatisiert durch die Pipeline geschleust. Wie kann so eine Pipeline für ein embedded Softwareprodukt nun aussehen und realisiert werden?
Beispiel für eine Continuous Delivery Pipeline
Schritt 1: Check-In
Die Änderungen werden vom Entwickler in das Versionsverwaltungssystem eingespielt.
Schritt 2: Build and compile
Ein Buildserver für die kontinuierliche Integration , z.B. Jenkins, bezieht den Sourcecode automatisiert, baut die Software und stellt die Binaries für die Testumgebung zur Verfügung.
Schritt 3: Unit Tests and Source Code Analysis
Ein Testserver führt automatisiert Unittests und Sorce Code Analysen durch, generiert Testreports und legt diese in einem Dokumentensystem ab.
Schritt 4: Automatisierte Integrationstests
Ein Testserver flasht die Binaries führt automatisierte Integrationstest durch, indem Eingänge durch Testtools stimuliert werden und Ausgangsgröße auswertet. Generierte Testreports warden in einem Dokumentensystem abgelegt.
Schritt 5: Deployment der Binaries.
Sind alle Schritte erfolgreich werden die Binaries automatisiert freigegeben und den betroffenen Abteilungen mit Bitte um Feedback zur Verfügung gestellt.
Dies alleine führt aber nicht zu einer besseren Qualität. Fehler gab es immer und wird es weiterhin geben. Das entscheidende ist: Wir erkennen sie viel früher, beheben sie schneller und effizienter, und reduzieren somit die Gesamtdurchlaufzeit drastisch. Darüber hinaus werden mühsame manuelle Tests fast vollends automatisiert. Dies spart wiederum Zeit.
Wo liegen nun die Herausforderungen? Nach meiner Erfahrung spielt auch das zwischenmenschliche eine eintscheidende Rolle. Es kann nicht mehr heißen: „Die Entwickler haben schon wieder ein fehlerhaftes Package geliefert“ oder „Die Vorlaufzeit im Betrieb ist ja ein Wahnsinn“. Vielmehr muss es ein Miteinander sein und nicht ein Austausch von Anschuldigungen, egal ob falsch oder auch berechtigt. Es muss sich ein natürliches WIR etablieren, ein Team entstehen, das sich nicht mehr getrennt voneinander sieht. Kurz: ein DevOps-Team!
So gesehen ist DevOps aus meiner Sicht auch mehr als eine besondere Methode. Im Wesentlichen ist eine gelebte Philosophie.
Sollten Sie Fragen haben, zum Beispiel zu eingesetzten Tools welche zur Unterstützung eingsetzt werden können, oder konkrete Lösungsvorschläge Ihr Projekt benötigen, schreiben Sie mir gerne eine eMail an s.schmidt@alsensio.de
Mit besten Grüßen,
Ihr Sebastian Schmidt