Zwei Hauptwege zur Bereitstellung einer J2EE / Java Web App (in einem sehr vereinfachten Sinne):
Hier erstellen wir die .war (oder was auch immer) an anderer Stelle, konfigurieren sie für die Produktion (möglicherweise erzeugen sie zahlreiche Artefakte für zahlreiche Boxen) und platzieren die resultierenden Artefakte auf den Produktionsservern.
Hier wird derselbe Prozess, der täglich zum Erstellen und Bereitstellen auf Entwicklerboxen verwendet wird, für die Bereitstellung in der Produktion verwendet.
Ich habe meistens den zweiten Prozess benutzt, allerdings aus der Notwendigkeit heraus (keine Zeit / Priorität für einen anderen Implementierungsprozess). Persönlich kaufe ich keine Argumente wie "die Produktionsbox muss von allen Compilern sauber sein, usw.", aber ich kann die Logik bei der Bereitstellung von dem, was Sie getestet haben, sehen (im Gegensatz zum Aufbau eines anderen Artefakt).
Java Enterprise-Anwendungen reagieren jedoch so empfindlich auf die Konfiguration, dass es sich anfühlt, als würden Sie zwei Prozesse zum Konfigurieren von Artefakten benötigen.
Gedanken?
Hier ist ein konkretes Beispiel:
Wir verwenden OSCache und aktivieren den Festplattencache. Die Konfigurationsdatei muss sich in der WAR-Datei befinden und verweist auf einen Dateipfad. Dieser Pfad unterscheidet sich in jeder Umgebung. Der Buildprozess erkennt den konfigurierten Standort des Benutzers und stellt sicher, dass die im Krieg platzierte Eigenschaftendatei für seine Umgebung korrekt ist.
Wenn wir den Build-Prozess für die Bereitstellung verwenden würden, wäre es wichtig, die richtige Konfiguration für die Produktionsumgebung zu erstellen (z. B. production.build.properties ).
Wenn wir die Methode "Zusammengesetzte Artefakte in die Produktionsbox deployen" verwenden, benötigen wir einen zusätzlichen Prozess, um die (inkorrekten) OSCache-Eigenschaften zu extrahieren und durch eine für die Produktionsumgebung geeignete zu ersetzen.
Dies erzeugt zwei Prozesse, um dasselbe zu erreichen.
Die Fragen lauten also:
Ich bin entschieden dagegen, auf der Produktionsbox zu bauen, weil das bedeutet, dass Sie einen anderen Build verwenden als Sie getestet haben. Es bedeutet auch, dass jeder Bereitstellungscomputer eine andere JAR / WAR-Datei hat. Wenn nichts anderes, machen Sie einen einheitlichen Build, so dass Sie sich bei der Fehlerverfolgung keine Gedanken über Inkonsistenzen zwischen Servern machen müssen.
Außerdem müssen Sie die Builds nicht in die Versionskontrolle stellen, wenn Sie einfach zwischen einem Build und der Quelle, die es erstellt hat, mappen können.
Wo ich arbeite, ist unser Bereitstellungsprozess wie folgt. (Dies ist unter Linux mit Tomcat.)
Testen Sie Änderungen und checken Sie in Subversion ein. (Nicht unbedingt in dieser Reihenfolge; wir verlangen nicht, dass der festgeschriebene Code getestet wird. Ich bin der einzige Vollzeit-Entwickler, daher ist der SVN-Baum im Wesentlichen mein Entwicklungszweig. Ihre Laufleistung kann variieren.)
Kopieren Sie die JAR / WAR-Dateien auf einen Produktionsserver in einem freigegebenen Verzeichnis, das nach der Subversion-Revisionsnummer benannt ist. Die Webserver haben nur Lesezugriff.
Das Bereitstellungsverzeichnis enthält relative symbolische Verknüpfungen zu den Dateien in den revisionsorientierten Verzeichnissen. Auf diese Weise zeigt eine Verzeichnisliste immer an, welche Version des Quellcodes die laufende Version erzeugt hat. Bei der Bereitstellung aktualisieren wir eine Protokolldatei, die kaum mehr als eine Verzeichnisliste darstellt. Das macht Rollbacks einfach. (Eine Frage, obwohl Tomcat nach dem Änderungsdatum der realen Datei nach neuen WAR-Dateien sucht, nicht nach dem Symlink. Daher müssen wir beim Zurücksetzen die alte Datei anfassen.)
Unsere Webserver entpacken die WAR-Dateien in ein lokales Verzeichnis. Der Ansatz ist skalierbar, da sich die WAR-Dateien auf einem einzigen Dateiserver befinden. Wir könnten eine unbegrenzte Anzahl von Webservern haben und nur eine einzige Bereitstellung durchführen.
Ich empfehle "Bereitstellen zusammengesetzter Artefakte in der Produktionsbox" wie eine WAR-Datei. Aus diesem Grund verwenden unsere Entwickler das gleiche Build-Skript (in unserem Fall Ant), um den Krieg in ihrer Entwicklungs-Sandbox zu konstruieren, der zum Erstellen des endgültigen Artefakts verwendet wird. Auf diese Art und Weise wird sowohl der Code selbst als auch der Code selbst debuggt, ganz zu schweigen davon, dass er vollständig wiederholbar ist.
Es gibt Konfigurationsdienste wie z. B. ZooKeeper , und die meisten Container ermöglichen die Verwendung von JNDI etwas Konfiguration. Dadurch wird die Konfiguration vom Build getrennt, aber es kann zu viel Overkill sein. Sie existieren jedoch. Viel hängt von Ihren Bedürfnissen ab.
Ich habe auch einen Prozess verwendet, bei dem die Artefakte mit Platzhaltern für Konfigurationswerte erstellt werden. Wenn der WAR bereitgestellt wird, wird er aufgelöst und die Platzhalter durch die entsprechenden Werte ersetzt.
Ich würde mich für den Einsatz einer Lösung für die kontinuierliche Integration einsetzen, die verteilte Builds unterstützt. Code, der in Ihren SCM eingecheckt wurde, kann Builds auslösen (für sofortige Tests), und Sie können Builds planen, um Artefakte für die Qualitätssicherung zu erstellen. Sie können diese Artefakte dann für die Produktion bereitstellen und sie bereitstellen lassen.
Dies ist derzeit, was ich an der Einrichtung arbeite, mit AnthillPro .
EDIT: Wir benutzen jetzt Hudson . Sehr zu empfehlen!
Wenn Sie diese Frage im Zusammenhang mit dem Konfigurationsmanagement stellen, muss Ihre Antwort darauf basieren, was Sie als verwaltetes Artefakt ansehen. Aus CM-Perspektive ist es eine inakzeptable Situation, dass eine Sammlung von Quelldateien in einer Umgebung und nicht in einer anderen Umgebung funktioniert. CM reagiert empfindlich auf Umgebungsvariablen, Optimierungseinstellungen, Compiler- und Laufzeitversionen usw. und Sie müssen diese Dinge berücksichtigen.
Wenn Sie diese Frage in Bezug auf wiederholbare Prozesse stellen, muss die Antwort auf dem Ort und der Menge des Schmerzes basieren, den Sie bereit sind zu tolerieren. Die Verwendung einer .war-Datei kann zu einem höheren Aufwand führen, um den Aufwand für Test- und Bereitstellungszyklen zu verringern. Durch die Verwendung von Quelldateien und Build-Tools können zwar Kosten eingespart werden, aber Sie müssen zusätzliche Probleme bei der späten Bearbeitung des Bereitstellungsprozesses ertragen.
Update für konkretes Beispiel
Zwei Dinge, die Sie in Bezug auf Ihr Beispiel beachten sollten.
Eine WAR-Datei ist nur eine ZIP-Datei mit einer alternativen Erweiterung. Sie können die Konfigurationsdatei durch standardmäßige Zip-Dienstprogramme ersetzen.
Überdenken Sie möglicherweise die Notwendigkeit, die Konfigurationsdatei in die WAR-Datei zu stellen. Wäre es ausreichend, wenn es im Klassenpfad vorhanden wäre oder Eigenschaften beim Start des Servers in der Ausführungsbefehlszeile angegeben wären.
Im Allgemeinen versuche ich, die Bereitstellungskonfigurationsanforderungen für den Bereitstellungsspeicherort beizubehalten.
Die Verwendung von 1 verpackten War-Dateien für Deploits ist eine gute Übung.
Wir verwenden Ameisen, um die Werte zu ersetzen, die in den verschiedenen Umgebungen unterschiedlich sind. Wir prüfen die Datei mit einer @@@ Variable, die durch unser Ameisen-Skript ersetzt wird. Das ant-Skript ersetzt das korrekte Element in der Datei und aktualisiert die WAR-Datei vor der Bereitstellung für jedes
Zusammenfassend macht es alles und wir benutzen Ameisenhaufen, um Ameisen zu verwalten. ant erstellt die WAR-Datei, ersetzt die Dateipfade, aktualisiert die WAR-Datei und stellt sie dann in der Zielumgebung bereit. Ein Prozess, in der Tat ein Klick auf einen Knopf in Ameisenhaufen.
Tags und Links java java-ee deployment