Im ersten Artikel meiner Beitragsserie “Time to Production” habe ich Best Practices aufgezeigt, um die Durchlaufzeit eines neuen Features von der Anforderung durch einen Produktverantwortlichen bis zum Abschluss der Entwicklung zu optimieren. Mit dem Abschluss der Softwareentwicklung steht das Feature jedoch noch nicht den Anwendern im Produktionssystem zur Verfügung. Die Idee, auch den zweiten Teil der Lieferkette nach der Übergabe eines Change an den Betreiber zu beschleunigen – und zwar ohne jeglichen Kompromiss bei Verfügbarkeit, Sicherheit oder sonstigen Qualitätsmerkmalen – ist naheliegend.
Beitragsserie: "Time to Production"
- Wie viel Agilität ist gut für die Softwareentwicklung?
- DevOps – der agile Systembetrieb
- DevSecOps – die Deployment-Pipeline für sichere Software
Bereichsübergreifende Kollaboration anstelle von Schuldzuweisungen
In der kommerziellen Softwareentwicklung haben wir gelernt, dass die Pflichten eines Auftraggebers bzw. Produktverantwortlichen nicht nur aus dem Erteilen eines Auftrags und dem Abzeichnen der Abnahmeerklärung bestehen. Die technische und fachliche Komplexität einerseits und der Zeitwettbewerb andererseits erfordern häufige zeitnahe Interaktionen, um Zulieferungen von Informationen und Infrastruktur zu steuern und notwendige Änderungen zu managen. So sind auch Entwicklung und Betrieb keine Silos. Sie müssen sich schon sehr früh über die Log- und Protokollausgaben der Anwendung abstimmen, die in der Produktionsumgebung automatisch geprüft werden sollen. Das gleiche gilt für Schnittstellen zwischen der Anwendung und Monitoring-Systemen, so dass diese überwachen können, ob kritische Komponenten noch “am Leben” sind, sowie für die Konfiguration der Systemumgebung und ihrer externen Schnittstellen. Die Qualitätssicherung muss bei ihren Tests möglichst die gleichen Versionsstände und Konfigurationen der Infrastrukturkomponenten einsetzen wie in der Produktionsumgebung. Systembetrieb und Produktverantwortlicher müssen sich über die erwartete Entwicklung der Systemlast, über Sicherheitsanforderungen usw. abstimmen.
Infrastructure as Code
Um schnell und flexibel auf Änderungen in Systemumgebungen reagieren zu können, müssen Systemadministratoren ähnlich vorgehen wie Softwareentwickler. Für alle administrativen Aufgaben sollten Skripte verfügbar sein und Konfigurationen von beispielsweise Servern oder virtuellen Maschinen sollten in Dateien abgelegt werden. Beides gehört unter die Obhut eines zentralen Versionsverwaltungssystems, mit dem Änderungen nachvollziehbar und reversibel sind. Vor ihrer Verwendung sollten neue Versionen der Skripte und Konfigurationen so getestet werden, dass die Tests alle Anwendungsfälle abdecken und ebenfalls nachvollziehbar sind.
Tools reduzieren den Aufwand
Für den Bereich der Systemüberwachung und Konfiguration gibt es heute zahlreiche Werkzeuge, die die Arbeit der Systemadministratoren erleichtern. Zur Unterstützung der Administration und des Konfigurationsmanagements komplexer Systemumgebungen hat PASS ein eigenes Tool entwickelt, den sogenannten PASS Application Cluster Manager (P.A.C.Man). Mit ihm lässt sich die Ausführung aller Skripte einer Systemumgebung zentral und unter Berücksichtigung ihrer Abhängigkeiten und relevanter Zustände planen oder manuell anstoßen. Gegenüber dem manuellen Handling der Skripte reduziert dieses Tool den Aufwand erheblich, außerdem erfordert es für die Administration weniger Expertenwissen und vermeidet Fehler.
Virtualisierung minimiert Risiken
Werkzeuge wie Vagrant und Docker können das Risiko reduzieren, das durch Abweichungen zwischen den Systemumgebungen für Test und Produktion entsteht. Die Produktionsumgebung wird vollständig, einschließlich Betriebssystem und aller Systemkomponenten, auf einer virtuellen Maschine betrieben. Das neue Release wird auf einer solchen virtuellen Maschine deployt und nach der Qualitätssicherung wird die virtuelle Maschine vollständig als Container in die Produktionsumgebung transportiert. Die Virtualisierung macht es möglich, dass der Entwicklungsprozess direkt auf die Produktionsumgebung zugreift – auf ihr virtuelles Abbild.
Continuous Delivery durch Automatisierung
Mit Hilfe geeigneter Tools kann der Build-Prozess aus dem Code Repository automatisiert werden. Toolbasierte Code-Analysen können nach definierten Regelwerken angestoßen und die weitere Verwendung des Builds von der Anzahl und Schwere der Regelverletzungen abhängig gemacht werden. Auch Unit Tests, Integrations- und Belastungstests sowie GUI-basierte funktionale Tests können mit entsprechenden Werkzeugen automatisiert werden. Hinzu kommt die automatisierte Verteilung der Komponenten in der Systemumgebung. All diese Schritte zusammen ergeben eine Deployment-Pipeline, mit der grundsätzlich jeder vom Entwickler in das Repository eingecheckte Code automatisch über mehrere Qualitätssicherungsstufen bis in die Produktionsumgebung laufen könnte.
Rein technisch wären wir damit in der Lage, die Time to Production auf eine Prozesslaufzeit zu reduzieren, die wir als Echtzeit empfinden würden. Abhängig von den Verfügbarkeitsanforderungen und den damit verbundenen Zeitfenstern für das Einspielen neuer Releases sowie Aspekten des Produktmanagements wird man die Entscheidung für einen Go-Live in der Regel nicht dem Entwickler überlassen. Sinnvoll ist, am Ende der Pipeline ein produktionsnahes Testsystem bzw. einen entsprechenden Container als Zwischenstopp und Entscheidungsgrundlage einzubauen. Die automatisierte Übernahme in die Produktionsumgebung erfolgt dann durch den menschlichen Entscheider auf Knopfdruck.
Das Modell DevOps bedeutet nicht mehr und nicht weniger als einen konsequenten Tooleinsatz sowie die zunehmende Automatisierung im Bereich des Systembetriebs – einhergehend mit einer engen Zusammenarbeit von Administratoren, Entwicklung, QS und Produktverantwortlichen. Agile Softwareentwicklung und DevOps sind das Instrumentarium, um die Time to Production spürbar zu reduzieren. Doch wo bleibt dabei die Sicherheit? Damit beschäftigt sich der dritte Beitrag dieser Reihe: “DevSecOps – die Deployment-Pipeline für sichere Software”.
Wie ausgeprägt ist das DevOps-Modell in Ihrer IT-Entwicklungs- und Systemlandschaft?
Bildquelle: Shutterstock
Dieser Beitrag hat einen Kommentar
Until a few years ago the division of this figure was right. The release was Ops-centric, and the deployment was also of Ops.
However, in organizations working on CI / CD, Dev is beginning to control including deployment. Such like whether it is a big Dev, a small Dev or not is similar to State theory.