Bei Continuous Delivery geht es um die Beseitigung von Verschwendung in der Softwareentwicklungspipeline

Am 22. Oktober werde ich auf der Continuous Delivery and DevOps Conference in Kopenhagen einen Vortrag halten, in dem ich meine Erfahrungen mit einer sehr erfolgreichen Implementierung einer neuen Website mit etwa 20.000.000 Seitenaufrufen pro Monat weitergeben werde. Die Komponenten und Inhalte für diese Website wurden von fünf(!) verschiedenen Anbietern entwickelt und für dieses Projekt ergriff der Kunde die Initiative, nach DevOps-Prinzipien zu arbeiten und einen vollständig automatisierten Softwarebereitstellungsprozess zu implementieren, während er weiterarbeitete. Dies war ein großer Gewinn für das Projekt, da sich die Entwicklungsteams nun auf die Bereitstellung neuer Software konzentrieren konnten, anstatt Probleme im Bereitstellungsprozess selbst zu beheben, und ich hatte das Glück, dies zu implementieren. In diesem Blog geht es um die Visualisierung der "Verschwendung", die wir im Rahmen des Projekts angegangen sind, wobei Sie die Diagramme vielleicht nützlich finden, wenn Sie die Prinzipien von Continuous Delivery in Ihrer eigenen Organisation vermitteln. Damit Sie nach den Prinzipien der kontinuierlichen Lieferung arbeiten können, ist ein effektiver Ausgangspunkt die Beseitigung von Verschwendung aus dem Softwareentwicklungsprozess. Wenn Sie sich einen herkömmlichen Softwareentwicklungsprozess ansehen, werden Sie feststellen, dass es in Ihrem bestehenden Prozess wahrscheinlich viele Bereiche gibt, die für den Kunden überhaupt keinen Mehrwert schaffen. Diese Bereiche sollten als reine Verschwendung betrachtet werden, die Ihrem Kunden keinen Mehrwert bringen und Sie entweder Zeit oder Geld (oder beides) kosten, und zwar immer und immer wieder. Jedes Mal, wenn neue Funktionen entwickelt und in die Produktion überführt werden, führen viele Mitarbeiter eine Menge kostspieliger manueller Arbeit aus und stoßen immer wieder auf die gleichen Probleme. Das nachstehende Diagramm zeigt ein Beispiel für häufige Bereiche, in denen Sie in Ihrer bestehenden Softwareentwicklungs-Pipeline Verschwendung finden könnten. Stellen Sie sich vor, dieser Prozess würde sich jedes Mal wiederholen, wenn ein Entwicklungsteam eine neue Software liefert. Vielleicht möchten Sie in Ihrem Gespräch ein ähnliches Diagramm verwenden, um Schmerzpunkte innerhalb Ihres derzeitigen Softwareentwicklungsprozesses zu erläutern. [caption id="attachment_13858" align="alignnone" width="713"] ein traditioneller Softwarebereitstellungsprozess[/caption] Bei der Automatisierung des Softwarebereitstellungsprozesses in diesem Projekt ging es darum, die bekannte Verschwendung so weit wie möglich zu beseitigen. Dies führte dazu, dass wir eine agile Projektstruktur einrichteten und begannen, nach DevOps-Prinzipien zu arbeiten, so dass das Team in der Lage war, Software in regelmäßigen Abständen zu liefern. Außerdem automatisierten wir den zentralen Build mit Jenkins CI, das den Code aus einem Git-Versionsverwaltungssystem auscheckt, den Code mit Maven kompiliert, die Komponenten in Apache Archiva speichert, statische, Unit- und funktionale Tests für die JEE- und PHP-Codebasis auslöst und Deployment Units für die weitere Verarbeitung in der Linie erstellt. Die Automatisierung des Deployments selbst wurde durch die Einführung von XL Deploy umgesetzt. Auf diese Weise wurden jedes Mal, wenn ein Entwickler neuen JEE- oder PHP-Code in das Git-Versionsverwaltungssystem einspeiste, sofort frisch gebackene Deployment-Einheiten in der Ziellandschaft bereitgestellt, die ihrerseits von Puppet verwaltet wurde. Im Folgenden finden Sie ein abstraktes Diagramm dieses Ansatzes und der gewählten Tools. [caption id="attachment_13859" align="alignnone" width="717"] Überblick über Tools zur Automatisierung des Softwarebereitstellungsprozesses[/caption] Wenn ich den Weg für Continuous Delivery ebne, bezeichne ich dies oft als Arbeit an den sechs A's: Aufbau von agilen (produktorientierten) Auslieferungsteams, Automatisierung des Builds, Automatisierung von Tests, Automatisierung von Deployments, Automatisierung der Bereitstellungsschicht und saubere, einfach zu handhabende Softwarearchitekturen. Bei dem A für Architektur geht es darum, sicherzustellen, dass die zu liefernde Software die Automatisierung des Softwarebereitstellungsprozesses selbst unterstützt und den Kunden in die Lage versetzt, nach den Prinzipien der kontinuierlichen Bereitstellung zu arbeiten. Dieses A ist im Diagramm nicht sichtbar. Nach der Automatisierung des Softwareauslieferungsprozesses verhielt sich der Softwareentwicklungsprozess des Kunden wie der unten dargestellte optimierte Prozess und bot dem Team die Möglichkeit, einen konstanten und fließenden Fluss neuer Funktionen für den Endbenutzer bereitzustellen. Vielleicht möchten Sie dieses Diagramm in Ihrem Gespräch verwenden, um die Vorteile für Ihr Unternehmen zu erläutern. [caption id="attachment_13861" align="alignnone" width="719"] ein optimierter Softwareauslieferungsprozess[/caption] Da wir die Softwareauslieferungspipeline für den Kunden automatisiert haben, konnten wir diesen Kunden in die Lage versetzen, mit einem Knopfdruck live zu gehen. Und am Tag des Go-Live war es genau das: ein Knopfdruck und 5 Minuten später war die Website komplett live. Das war die langweiligste Go-Live-Veranstaltung, die ich je erlebt habe. Das Projekt an sich hat aber sehr viel Spaß gemacht! :) Unnötig zu erwähnen, dass nachfolgende Aktualisierungen jetzt innerhalb weniger Minuten in den Live-Status überführt werden, da der gesamte Prozess sehr zuverlässig geworden ist. Das Deployment von Code wurde zu einem Nicht-Ereignis. Weitere Einzelheiten darüber, wie wir dieses Projekt zu einem vollen Erfolg gemacht haben, wie wir diese Umgebung implementiert haben, den Projektrahmen, die gewählten Tools und technische Details werde ich gerne auf der Continuous Delivery and DevOps Conference in Kopenhagen erläutern. Aber natürlich können Sie mich auch direkt kontaktieren. Bis dahin hoffe ich, Sie dort zu treffen. Michiel Sens.