DevOps in der Praxis
In der Theorie ist DevOps ein strategischer Ansatz, der Entwickler und Admins näher zusammenbringen und damit agile Entwicklungsmethoden ermöglichen soll. Funktioniert das in der Realität?
- Uwe Geier
In der Theorie ist DevOps ein strategischer Ansatz, der Entwickler und Admins näher zusammenbringen und damit agile Entwicklungsmethoden ermöglichen soll. Funktioniert das in der Realität?
Kein Unternehmen wirft von einem Tag auf den anderen seine Softwareentwicklungsprozesse über den Haufen und arbeitet nach agilen Methoden. Vielmehr schleichen sich Herangehensweisen wie DevOps ein. Da sind zum einen die Anforderungen des Markts, Produkte und Service schneller und effizienter zur Verfügung zu stellen. Zum anderen hat der Erfolg von DevOps auch etwas mit einem Kulturwandel zu tun.
Agile Methoden – im Kleinen längst bewährt
Meist ist es ein kleines Problem, für das eine schnelle Lösung benötigt wird: Eine Test-Routine muss mal eben programmiert, eine Schnittstelle zwischen zwei Anwendungen ein wenig angepasst werden oder Ähnliches. Es ist weder Zeit noch besteht die Notwendigkeit, hierfür einen klassischen Entwicklungsprozess anzustoßen. Ein kleines Team findet sich zusammen, spricht die Anforderungen und Abhängigkeiten ab und legt los. Der Entwickler stellt dem Administrator das Programmierte vor, dieser regt weitere Verbesserungen an, damit die Integration und der Betrieb reibungslos funktionieren. Der Entwickler überarbeitet sein Werk und lässt den Admin erneut prüfen und testen. Fertig.
So oder so ähnlich verlaufen die ersten DevOps-Schritte – aus der täglichen Arbeit heraus und ohne darüber nachzudenken, ob diese Vorgehensweise nun einen Namen hat oder nicht. Die Vorteile: kurze Abstimmungswege und schnelle Erfolge. Diese Art und Weise der Softwareentwicklung eignet sich auch für größere Projekte, etwa der Entwicklung von Apps oder Modulen. Dabei werden die Teams nicht mehr nach ihrer Funktion zusammengestellt, sondern nach Use Cases.
Ein Beispiel: Eine größere Softwareapplikation benötigt ein neues Feature, etwa um einen neuen Partner in den Produktionsprozess einbinden oder sicher mobil auf die Anwendung zugreifen zu können. Der Use Case ist damit klar definiert und mit ihm das Ziel, das erreicht werden soll. Der Projektleiter holt nun die Entwickler und die für den Betrieb der Software verantwortlichen Admins an einen Tisch. Die Anforderungen aller Beteiligten werden diskutiert und dokumentiert. Regelmäßige Meetings dieser Art in kurzen Abständen haben sich bewährt. Beispielsweise kann sich das Team täglich zum Arbeitsbeginn kurz abstimmen. Da immer alle beteiligt sind, fließen Änderungen viel schneller und im laufenden Prozess ein. Das Risiko, dass im Nachhinein noch viele Bugfixes einzuspielen sind, sinkt deutlich.
Offene Enden und Mangel an Konzeption
Das klingt einfach umsetzbar – und das ist es tatsächlich. In der täglichen Praxis gibt es kaum echte Reibungspunkte, die nicht fachlich zu klären wären. Dass es Entwicklern egal wäre, ob ihre App später auf der Infrastruktur auch wirklich läuft, und dass Admins stets schlecht auf Entwickler zu sprechen seien, da diese unadministrierbare Software entwickelten, ist eine Mär. Fachliche Diskussionen in frühen Entwicklungsstadien sind hingegen ausdrücklich erwünscht und machen den Kern dessen aus, was DevOps sein soll. Denn ob beispielsweise wegen der besseren Versionierbarkeit ein ganzes Paket programmiert oder doch in einem Git-Repository eingespielt wird, lässt sich so frühzeitig ausdiskutieren und fällt nicht im Nachhinein auf die Entwickler zurück.
Dennoch: Ein Softwareentwicklungsprojekt besteht nicht nur aus kleinen Apps. Agile Methoden leben mit dem Risiko, zu wenig Aufwand in die Anfangskonzeption zu stecken und damit Spaghetti-Code zu produzieren, der sich schließlich nur noch mit hohem Aufwand pflegen lässt. Klassische Softwareentwicklung startet für gewöhnlich mit einem Pflichtenheft und einem sorgfältig durchdachten Konzept, das spätere Integrationen und Erweiterungen bedenkt. Das ist und bleibt auch sinnvoll, vor allem wenn es sich um generalistische Software wie ERP-Systeme handelt.
Doch die meisten anderen Anwendungen haben ihre Halbwertszeit deutlich verkürzt. Der Softwarelebenszyklus beträgt bestenfalls noch wenige Jahre; zu schnell und grundlegend entwickeln sich Techniken weiter. So passiert es zum einen, dass eine Software ganz neu aufzusetzen ist, weil neue Feature konzeptionell nicht bedacht wurden und sich nun nicht mehr integrieren lassen. Zum anderen haben sich viele Apps aber nach wenigen Jahren bereits überlebt und eine Erweiterung wäre aufwendiger als eine Neuprogrammierung mit modernen Werkzeugen.
