Wie können wir unseren Build- und Bereitstellungsprozess verbessern?

Question

Unser Build/Deploy-Prozess ist sehr mühsam, ausreichend manuell und fehleranfällig. Können Sie Verbesserungsvorschläge machen?

Lassen Sie mich unsere Bereitstellungsstrategie und den Buildprozess beschreiben. Wir entwickeln ein System namens Application Server (kurz AS). Es handelt sich im Wesentlichen um eine servletbasierte Webanwendung, die auf dem JBoss-Webserver gehostet wird. AS kann in zwei "Umgebungen" installiert werden. Jede Umgebung ist ein Verzeichnis mit dem Webapp-Code. Dieses Verzeichnis befindet sich im Netzwerkspeicher. Der Speicher ist auf mehreren Produktionsservern installiert, auf denen JBoss-Instanzen installiert sind. Das Verzeichnis ist mit dem Verzeichnis webapps von JBoss verknüpft. Daher verwenden alle JBoss-Instanzen denselben Code für die Umgebung. Die Konfiguration von JBoss ist unabhängig von der Umgebung und wird pro Instanz aktualisiert.

So haben wir zwei Arten von Patches: Webapp Patches (für unterschiedliche Umgebungen) und Konfigurations Patches (für pro Instanz-Konfiguration)

Patch ist eine ausführbare Datei. Tatsächlich ist es ein Bash-Skript mit einem eingebetteten binären RPM-Paket. Die Installation ist ziemlich einfach: Sie führen nur die Datei aus und beantworten optional einige Fragen. Wichtig ist, dass es sich bei dem Patch nicht um ein Gesamtsystem handelt - es enthält nur einige Klassen mit Fixes und/oder Skripten, die Konfigurationsdateien modifizieren. Klassen werden in WEB-INF/-Klassen kopiert (AS wird als Explosionsverzeichnis bereitgestellt).

Die Art, wie wir diese pathes bauen ist:

1. Wir nehmen einige frühere Patch-Dateien und kopieren Sie sie.
2. Wir ändern den Inhalt des Patches. Der wichtigste Teil davon ist RPM-Spezifikation. Dort ändern wir den Namen des Patches, ändern seine vorausgesetzten RPM-Pakete und schreiben die eigentlichen Bash-Befehle zum Sichern, Kopieren und Ändern von Dateien auf. Dies ist einer der ärgerlichsten Teile, weil wir nicht immer die tatsächliche Änderung erhalten können. Dies gilt insbesondere für neue komplexe Funktionen, die sich auf mehrere Änderungsanforderungen und -befehle erstrecken. Außerdem ist das Schreiben dieser Befehle für den Änderungssatz mühsam und fehleranfällig.
3. Für Webapp-Patches ändern wir auch Spezifikationen für andere Umgebungen. Normalerweise sind sie identisch mit Ausnahme des RPM-Paketnamens.
4. Wir setzen alle rpm bezogenen Dateien auf VCS
5. Wir ändern build.xml, indem Sie ein paar Ziele für die Erstellung neuer Patches hinzufügen. Die Änderung erfolgt durch Kopieren und Bearbeiten.
6. Wir ändern CruiseControl- config von Projekt copypasting und wechselnden ant Ziele darin
7. Endlich bauen wir ein System

Auch ich habe Interesse an irgendwelchen Referenzen auf Patch-Vorbereitung und Bereitstellung Praktiken, vorzugsweise für Java-Anwendungen. Ich habe es nicht geschafft, das zu googeln.

Answer 1

Der Ort, an dem ich arbeitete, hatte ähnliche Probleme, aber vielleicht nicht so komplex.

Wir reagierten, indem wir das Konzept des Patches komplett eliminierten. Wir hörten auf zu patchen und begannen einfach die gesamte App zu installieren (selbst wenn wir nur eine kleine Änderung vornehmen).

Wir haben jetzt Cruise Control bauen komplette Installationssätze, die den Build-Zeitstempel in der Installation-Kit-Namen enthalten. Dies ist ein Cruise Control Build-Artefakt.

Cruise Control installiert sie automatisch auf einem Testserver und führt einige automatisierte Rauchtests durch. Wir führen dann manuelle Tests auf dem Testserver aus.Dann installieren wir das Artefakt auf einem Staging-, dann Produktionsserver.

Die Beseitigung von Patching verursachte einige Leute zu stottern, "ist das nicht verschwenderisch, wenn Sie nur ein paar Dinge ändern?" und "Warum sollten Sie die gesamte Software überschreiben, nur um etwas zu patchen?"

Aber die Wahrheit ist, dass eine gute Quellcodeverwaltung, ein automatisierter Install-Kit-Bau und eine Ein-Schritt-Installation uns eine Menge Zeit gespart hat. Es dauert ein paar Sekunden länger zu installieren, aber wir können es viel öfter und mit weniger Entwicklerarbeit machen.

Answer 2

Wir versuchen auch, Patch-/Hotfix-Versionen zu veröffentlichen und komplette Installationspakete basierend auf RPM freizugeben.

Ich muss sagen, ich stimme auch zu, dass dieser Aufwand in den meisten Fällen eine Verschwendung ist und ich würde auch für die Freigabe des vollständigen Installationspakets gehen, vorausgesetzt, Sie haben bereits eine etablierte Build-Pipeline.

In unserem Fall haben wir eine Multi-Modul-Lieferung jeweils verpackt als RPM und verpackt in einem ISO für die Lieferung. Wir beabsichtigen, unsere Build-Pipeline für die Veröffentlichung von Hotfixes weitgehend unverändert zu lassen. Daher konzentrieren wir uns stattdessen darauf, unsere RPMs feiner zu machen (kleinere - gezieltere RPMs), so dass wir nur die RPMs freigeben können, die veränderte Artefakte für einen bestimmten Hotfix/Patch enthalten.

Auf diese Weise sind die RPMs und Patch-RPMs in voller Version identisch, der einzige Unterschied ist die Anzahl der RPMs, die Sie in Ihrer Liefer-ISO verpacken.

Ich habe eine andere Frage Lösung dieses Problems kann man sich dort einen Blick:

hotfix-patch-build-delivery-approach