Praxiserfahrung DevOps – DevOps was?

Immer noch oft höre ich: DevOps, was? Deshalb möchte ich hier heute einen Einblick in die Praxis mit DevOps geben.

In der Theorie beschreibt DevOps einen Ansatz zur Prozessverbesserung in der Softwareentwicklung und der Systemadministration. Soweit die Theorie. Doch zuerst sollte man sich bewusst sein, was zu verbessern ist. Bei uns war das relativ einfach: Wir hatten immer wie mehr Schnittstellen und konnten es uns nicht mehr leisten, nur zweimal im Jahr neue Software-Releases auszuliefern.

Einfach nur eine Lösung in der Softwareentwicklung oder der Systemadministration zu suchen, griff hier zu kurz. So mussten wir uns die Art, wie wir die Software warten, neue Features entwickeln und auch, wie die Software zum Kunden kommt und dort betrieben wird, anschauen.

In der organisatorischen Konsequenz hiess dies, die Bereiche Softwareentwicklung und Systemadministration müssen zusammenarbeiten, um die Software öfters und effizienter auszuliefern. Auch sollte die Rolle des Produktmanagers gestärkt werden.

Unser Ziel war: Weg von der imperativen Arbeitsweise (Befehle manuell abzusetzen) zu mehr Automation.

Build-Systeme

Die Software war und ist zwar modular aufgebaut, d.h. wir konnten immer auch nur einzelne Softwareteile ausliefern. Dies geschah aber durch den Entwickler und nicht durch ein Build-System.

Hier war der erste Schritt der Einsatz eines Build-Systems. Da grosse Teile der Applikationen in Java programmiert sind, bot sich hier Maven (https://de.wikipedia.org/wiki/Apache_Maven) an.

Dies erlaubte es, das Build der Software vom Entwickler zu einem Continuous-Integration-System zu verlagern und zu automatisieren. Positiv ist zu erwähnen, dass Maven auch Unit Tests, Prüfen der Codequalität bis zum Erstellen von Containern unterstützt.

Source Code Management

Eine modulare Software hilft aber noch nicht, die Übersicht über Änderungen zu bekommen oder diese effizient zu steuern und zu dokumentieren.

Da wir schon seit Beginn der Softwareentwicklung CVS (https://de.wikipedia.org/wiki/CVS) im Einsatz hatten, waren uns Source-Code-Management-Systeme nicht fremd. Dies gab und gibt uns seit Anbeginn der Softwareentwicklung einen guten Überblick über alle Änderungen und Erweiterungen.

Wer CVS kennt, weiss aber, dass es eine grosses Manko im Bereich Branches (Verzweigungen von Software-Ästen) aufweist. Musste doch für einen grossen Release immer das komplette CVS-Repository 1:1 kopiert werden und Änderungen, die den alten und neuen Release betrafen, doppelt nachgeführt werden.

Deshalb drängte sich der Umstieg auf Git (https://de.wikipedia.org/wiki/Git) auf, das Branches effizient unterstützt.

Dadurch konnte nicht nur das Problem der Releases gelöst werden, sondern heute werden Branches auch zur Implementierung von neuen Features, Hotfixes usw. genutzt.

Continuous Integration (CI) mit Jenkins

Nachdem wir die Problematik Build und Source Code Management gelöst hatten, konnten wir den nächsten Schritt wagen und Continuous Integration angehen. Bei «Continuous Integration» geht es um die fortlaufende permanente Integration von Komponenten zu einer Anwendung.

Dieses lässt sich mittels Jenkins (https://de.wikipedia.org/wiki/Jenkins_(Software)) und ein wenig Shellscripts (neu Jenkinsfile) hervorragend umsetzen. Das umso mehr, als Jenkins mit Git und Maven Hand in Hand zusammenarbeitet.

Das Zusammenbauen der Software zu einer Anwendung konnte nun an Jenkins delegiert werden.

Im Zusammenspiel Git/Jenkins wurde auch die Rolle des Produktmanagers gestärkt. Dieser kann nun selbstständig entscheiden, welche Features in einen Release einfliessen sollen. Dazu vereinigt er die Feature-Git-Branches mit dem Release und lässt diesen durch Jenkins builden. Nach diversen Tests entscheidet der Produktmanager, ob das Resultat an den Kunden ausgeliefert wird.

Automatisierte Tests und Qualitätsüberprüfungen

Continuous-Integration-Systeme wie Jenkins haben aber noch eine Vielzahl von Funktionen wie Unit-Tests, Prüfung der Codequalität (z.B. Checkstyle), Auswertung von Tags wie FIXME (Kritische Fehler) oder TODO (zu erledigen) in Code.

Diese Auswertungen sind einfach als Jenkins-Plug-Ins zu installieren und ermöglichen eine laufende Qualitätssicherung der Software.

Deployment der Artefakte aus der CI Pipeline als Container

Wie am Anfang erwähnt, hat DevOps auch Auswirkungen auf die Systemadministration. Konnten oben beschriebene Komponenten und Systeme grösstenteils ohne die  Systemadministration ausgeführt werden, braucht es für das Deployment der Anwendung die Systemadministration.

Als wir vor 6 Jahren mit dem DevOps-Ansatz begannen, waren Container noch nicht oder in einem sehr frühen Entwicklungssystem vorhanden. Deshalb entschieden wir uns, die Software und Umsysteme (Datenbank, Filesharing usw.) in virtuellen Maschinen auszuliefern.

Die Installation und das Deployment der Anwendungen wurden durch Shellscripts automatisiert.

Neue Anwendungen werden in Container ausgeliefert. Das hat sich sehr bewährt. Dadurch konnten die Abläufe mehr standardisiert und vereinheitlicht werden. Kubernetes befindet sich im Testeinsatz und soll dieses Jahr grossflächig ausgeliefert werden, um so die virtuellen Maschinen abzulösen.

Was hat uns DevOps gebracht?

Was als Projekt mit ungewissem Ausgang begann, ist heute aus der Firma nicht mehr wegzudenken. Die Aufwände haben sich mehr als gelohnt. Probleme, die früher einen Entwickler benötigten, können heute vom Produktmanager oder der Kundenbetreuung selbstständig gelöst werden. Die eingesetzten Open-Source-Tools haben sich in der Produktion bewährt und können wärmstens weiterempfohlen werden. Mittels der kleinen und häufigeren Releases statt der zwei Big-Bang-Releases ist die Stimmung im Team entspannter und es kann schneller auf Kundenwünsche oder evtl. auftretende Probleme reagiert werden.