Kontinuierliche Bereitstellung über mehrere Anbieter hinweg

Im letzten Jahr hatten drei der vier Kunden, mit denen ich gearbeitet habe, ein ähnliches Problem mit ihren Umgebungen. In unterschiedlichen Variationen hatten sie alle ihre Umgebungen in getrennten Domänen eingerichtet. Das reichte von physisch getrennten Netzwerken vor Ort bis hin zu Umgebungen, die bei verschiedenen Hosting-Anbietern liefen, die von unterschiedlichen Parteien verwaltet wurden.

Unabhängig von den Gründen für diese Art von Einrichtung ist dies eine Situation, in der die Konzepte der kontinuierlichen Bereitstellung einen echten Mehrwert bieten. Die stereotypen Probleme, die bei manuellen Bereitstellungs- und Testverfahren auftreten, werden in der Regel noch verstärkt, wenn sie in getrennten Bereichen auftreten. Noch schlimmer wird es, wenn weitere Parteien hinzukommen (wie externe Anwendungsentwickler). Das Festhalten an der manuellen Vorgehensweise ist ein Rezept für eine Katastrophe, es sei denn, Sie haben Spaß daran, jedes Mal, wenn Sie etwas in "Ihrer" Umgebung tun wollen, umfangreiche Verfahren zu durchlaufen. Und wenn Sie Ihre Umgebungen an eine externe Partei ausgelagert haben, möchten Sie wahrscheinlich nicht viele Mitarbeiter (wieder) einstellen müssen, nur damit Sie mit Ihrem Lieferanten kommunizieren können.

Wie kann Continuous Delivery also in dieser Situation helfen? Indem Sie die Bereitstellung und den Einsatz automatisieren, machen Sie die Bereitstellung Ihrer Anwendungen zumindest wiederholbar und vorhersehbar. Unabhängig davon, wo sie ausgeführt werden müssen.

Es reicht jedoch nicht aus, nur die Bereitstellung zu automatisieren. Es stellt sich die Frage, wer was macht. Eine Frage, die höchstwahrscheinlich durch einen langwierigen Vertrag untermauert wird. Die Verträge zwischen allen Parteien sollen eine Antwort auf diese Frage geben. Ein Entwicklungspartner entwickelt, ein Outsourcing-Partner kümmert sich um die Hardware, usw. Aber niemand kümmert sich darum, alles unter einen Hut zu bringen...

Der Prozess der Automatisierung Ihrer Arbeitsschritte bietet bereits eine gewisse Hilfe bei diesem Problem. Um zu automatisieren, brauchen Sie eine Art Vereinbarung darüber, wie Sie den Input für das Tooling bereitstellen. Dadurch wird zumindest geklärt, was die verschiedenen Parteien zu leisten haben. Es ist auch klar, was das Ergebnis eines Schrittes sein wird. Dadurch werden einige Unschärfen aus dem Prozess entfernt. Dinge wie die Frage, ob die JVM Teil des Betriebssystems oder Teil der Middleware ist, sollten nun klar sein. Aber nicht alles ist so klar. Es sind die Teile des Puzzles, in denen die Teile tatsächlich zusammenkommen, die die Dinge grau erscheinen lassen. Ein einzelnes Tool benötigt möglicherweise Input von verschiedenen Parteien. Hier müssen Sie sich gegen die übliche reflexartige Reaktion wehren, das besagte Tool durch Verfahren und Bürokratie von anderen Personen abzuschirmen. Bieten Sie stattdessen allen Beteiligten Zugang zu diesen Tools und sorgen Sie für eine Trennung der Interessen durch einen zuverlässigen Zugangsmechanismus. Selbst dann könnte es Teile geben, die nicht nur von einer einzigen Partei genutzt werden können, und in diesem Fall, *gasp*, müssen die Leute zusammenarbeiten.

Das Ergebnis ist eine automatisierte Pipeline, die dafür sorgt, dass Ihre Umgebungen ordnungsgemäß konfiguriert sind und Anwendungen bei Bedarf innerhalb von Minuten auf ihnen bereitgestellt werden können, unabhängig davon, wo sie laufen.

Das obige Diagramm zeigt, wie wir dies für einen unserer Kunden eingerichtet haben. Wir verwenden XL Deploy, XL Release und Puppet als Automatisierungswerkzeug der Wahl.

In der ersten Domäne haben wir ein Git-Repository, an das die Entwickler ihren Code übergeben. Ein Jenkins-Build wird verwendet, um diesen Code zu extrahieren, zu erstellen und so zu verpacken, dass das Automatisierungswerkzeug für die Bereitstellung (XL Deploy) ihn versteht. Es ist auch so freundlich, dieses Paket direkt in XL Deploy verfügbar zu machen. Von dort aus wird XL Deploy verwendet, um die Anwendung nicht nur auf den Zielcomputern bereitzustellen, sondern auch auf einer anderen Instanz von XL Deploy, die in der nächsten Domäne läuft, so dass dasselbe Paket auch dort bereitgestellt werden kann. Derselbe Mechanismus kann dann auf die nächste Domäne angewendet werden. In diesem Fall stellen wir sicher, dass die Rechner, auf denen wir die Anwendung bereitstellen, konsistent sind, indem wir sie mit Puppet verwalten.

Zur Abrundung verwenden wir eine einzige Instanz von XL Release, um die gesamte Pipeline zu orchestrieren. Ein einziger Release-Prozess ist in der Lage, den Build in Jenkins auszulösen und die Anwendung dann in allen Umgebungen in den verschiedenen Domänen bereitzustellen.

Ein solches Setup verringert die Fehler bei der Bereitstellung, die bei manuellen Bereitstellungen auftreten, und erspart Ihnen den ganzen Ärger, der mit der Einhaltung der erforderlichen Verfahren verbunden ist. Als zusätzlicher Bonus beschleunigt sich Ihre Bereitstellungspipeline erheblich. Und wir haben noch gar nicht darüber gesprochen, wie Sie automatisierte Tests in den Mix integrieren können...