Java Web Deployment: Code erstellen oder .war bereitstellen?

Question

Es gibt zwei Hauptmöglichkeiten, eine J2EE/Java-Webanwendung bereitzustellen (in einem sehr vereinfachten Sinne):

Bereitstellung der zusammengestellten Artefakte in der Produktionsbox

Hier erstellen wir die .war (oder was auch immer), konfigurieren Sie es für die Produktion (möglicherweise erstellen Sie zahlreiche Artefakte für zahlreiche Boxen) und platzieren Sie die resultierenden Artefakte auf den Produktionsservern.

• Profis : Keine Entwicklungswerkzeuge auf den Produktionssystemen, direkte Wiederverwendung von Artefakten aus den Tests, Mitarbeiter, die für die Bereitstellung zuständig sind, benötigen keine Kenntnisse des Build-Prozesses
• Nachteile Zwei Prozesse für die Erstellung und Bereitstellung von Artefakten; potenziell komplexe Konfiguration von vorgefertigten Artefakten könnte den Prozess schwer skriptbar/automatisierbar machen; binäre Artefakte müssen versioniert werden

Erstellen der Artefakte auf die Produktionsbox

Hier wird derselbe Prozess, der täglich für die Erstellung und Bereitstellung auf lokalen Entwicklungssystemen verwendet wird, auch für die Bereitstellung in der Produktion genutzt.

• Profis : Ein zu pflegender Prozess, der durch häufige Nutzung intensiv getestet/validiert wird. Möglicherweise ist es einfacher, die Konfiguration bei der Erstellung des Artefakts anzupassen, als das vorgefertigte Artefakt nachträglich zu ändern; keine Versionierung von binären Artefakten erforderlich.
• Nachteile : Potenziell komplexe Entwicklungstools, die auf allen Produktionssystemen benötigt werden; das Bereitstellungspersonal muss den Build-Prozess verstehen; Sie sind nicht Bereitstellung der getesteten Daten

Ich habe meist den zweiten Prozess verwendet, zugegebenermaßen aus der Not heraus (keine Zeit/Priorität für einen anderen Verteilungsprozess). Ich persönlich glaube nicht an Argumente wie "die Produktionsbox muss frei von allen Compilern usw. sein", aber ich kann die Logik des Einsatzes des Getesteten (im Gegensatz zur Erstellung eines weiteren Artefakts) zu verstehen.

Java-Enterprise-Anwendungen sind jedoch so konfigurationsempfindlich, dass zwei Prozesse für die Konfiguration von Artefakten eher ein Problem darstellen.

Was denken Sie?

Update

Hier ein konkretes Beispiel:

Wir verwenden OSCache und aktivieren den Festplatten-Cache. Die Konfigurationsdatei muss sich innerhalb der .war-Datei befinden und verweist auf einen Dateipfad. Dieser Pfad ist in jeder Umgebung anders. Der Build-Prozess erkennt den konfigurierten Speicherort des Benutzers und stellt sicher, dass die in der War-Datei enthaltene Eigenschaftsdatei für seine Umgebung korrekt ist.

Wenn wir den Build-Prozess für die Bereitstellung verwenden würden, müssten wir die richtige Konfiguration für die Produktionsumgebung erstellen (z. B. production.build.properties ).

Wenn wir die "Bereitstellung der zusammengestellten Artefakte in der Produktionsumgebung" befolgen würden, bräuchten wir einen zusätzlichen Prozess, um die (falschen) OSCache-Eigenschaften zu extrahieren und sie durch eine für die Produktionsumgebung geeignete zu ersetzen.

Dies führt zu zwei Prozessen, um dieselbe Sache zu erreichen.

Die Fragen lauten also:

• Lässt sich dies ohne "Kompilieren in der Produktion" vermeiden?
• Wenn nicht, ist es das wert? Ist der Wert von "keine Kompilierung bei der Produktion" größer als "wiederhole dich nicht"?

Answer 1

Wenn Sie diese Frage in Bezug auf das Konfigurationsmanagement stellen, dann muss Ihre Antwort darauf basieren, was Sie als verwaltetes Artefakt betrachten. Aus der CM-Perspektive ist es eine inakzeptable Situation, wenn eine Sammlung von Quelldateien in einer Umgebung funktioniert und in einer anderen nicht. CM ist empfindlich gegenüber Umgebungsvariablen, Optimierungseinstellungen, Compiler- und Laufzeitversionen usw., und Sie müssen diese Dinge berücksichtigen.

Wenn Sie diese Frage in Bezug auf die Schaffung eines wiederholbaren Prozesses stellen, dann muss die Antwort auf der Grundlage des Ortes und der Menge des Schmerzes erfolgen, den Sie bereit sind zu tolerieren. Die Verwendung einer .war-Datei kann mit mehr Aufwand verbunden sein, um bei den Test- und Bereitstellungszyklen Zeit zu sparen. Die Verwendung von Quelldateien und Build-Tools kann im Vorfeld Kosten sparen, aber Sie müssen zusätzliche Schmerzen bei der Behandlung von Problemen in der späten Phase des Bereitstellungsprozesses in Kauf nehmen.

Aktualisierung für ein konkretes Beispiel

Zwei Dinge sind in Bezug auf Ihr Beispiel zu beachten.

1. Eine .war-Datei ist einfach eine .zip-Datei mit einer anderen Erweiterung. Sie können die Konfigurationsdatei an Ort und Stelle mit Standard-Zip-Dienstprogrammen ersetzen.

2. Überdenken Sie eventuell die Notwendigkeit, die Konfigurationsdatei in die .war-Datei aufzunehmen. Wäre es ausreichend, sie im Klassenpfad zu haben oder die Eigenschaften in der Ausführungsbefehlszeile beim Start des Servers anzugeben?

Im Allgemeinen versuche ich, die Anforderungen an die Einsatzkonfiguration auf den Einsatzort abzustimmen.

Answer 2

Die Verwendung von 1 gepackten War-Dateien für Deploys ist eine gute Praxis.
verwenden wir Ameisen, um die Werte zu ersetzen, die zwischen den Umgebungen unterschiedlich sind. Wir checken die Datei mit einer @@@-Variable ein, die von unserem Ameisenskript ersetzt wird. Das Ameisenskript ersetzt das korrekte Element in der Datei und aktualisiert dann die War-Datei vor der Verteilung an jede

<replace file="${BUILDS.ROOT}/DefaultWebApp/WEB-INF/classes/log4j.xml" token="@@@" value="${LOG4J.WEBSPHERE.LOGS}"/>

<!-- update the war file We don't want the source files in the war file.-->
<war basedir="${BUILDS.ROOT}/DefaultWebApp" destfile="${BUILDS.ROOT}/myThomson.war" excludes="WEB-INF/src/**" update="true"/>

Zusammenfassend lässt sich sagen, dass die Ameise alles macht und wir den Ameisenhaufen zur Verwaltung der Ameisen nutzen. ant erstellt die War-Datei, ersetzt die Dateipfade, aktualisiert die War-Datei und stellt sie dann in der Zielumgebung bereit. Ein einziger Prozess, genau genommen ein Klick auf eine Schaltfläche in Anthill.