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

Ich bin strikt dagegen, auf der Produktionsbox zu bauen, denn das bedeutet, dass Sie ein anderes Build verwenden als das, mit dem Sie getestet haben. Es bedeutet auch, dass jeder Einsatzrechner eine andere JAR/WAR-Datei hat. Zumindest sollten Sie einen einheitlichen Build erstellen, damit Sie sich bei der Fehlersuche keine Gedanken über Inkonsistenzen zwischen den Servern machen müssen.

Außerdem brauchen Sie die Builds nicht in die Versionskontrolle zu geben, wenn Sie leicht eine Zuordnung zwischen einem Build und dem Quellcode, der es erstellt hat, herstellen können.

Dort, wo ich arbeite, läuft der Einsatz folgendermaßen ab. (Dies ist auf Linux, mit Tomcat.)

1. Änderungen testen und in Subversion einchecken. (Nicht unbedingt in dieser Reihenfolge; wir verlangen nicht, dass übergebener Code getestet wird. Ich bin der einzige Vollzeitentwickler, also ist der SVN-Baum im Wesentlichen mein Entwicklungszweig. Ihre Erfahrungen können variieren.)

2. Kopieren Sie die JAR/WAR-Dateien auf einen Produktionsserver in ein gemeinsames Verzeichnis, das nach der Subversion-Revisionsnummer benannt ist. Die Webserver haben nur Lesezugriff.

3. Das Bereitstellungsverzeichnis enthält relative Symlinks zu den Dateien in den Verzeichnissen mit den Revisionsnamen. Auf diese Weise zeigt eine Verzeichnisauflistung immer an, welche Version des Quellcodes die laufende Version erzeugt hat. Beim Deployment aktualisieren wir eine Protokolldatei, die kaum mehr als eine Verzeichnisliste ist. Das macht Rollbacks einfach. (Allerdings gibt es einen Haken: Tomcat sucht nach neuen WAR-Dateien anhand des Änderungsdatums der echten Datei, nicht des Symlinks, so dass wir beim Rollback die alte Datei anfassen müssen).

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 vornehmen.

Answer 2

In den meisten Unternehmen, in denen ich gearbeitet habe, wurde die erste Methode angewandt, bei der die umgebungsspezifischen Konfigurationsinformationen separat (und sehr viel seltener) außerhalb des War/ear bereitgestellt wurden.

Answer 3

Es gibt Konfigurationsdienste, wie z.B. Heavy Weight ZooKeeper und die meisten Container ermöglichen die Verwendung von JNDI für die Konfiguration. Dadurch wird die Konfiguration von der Erstellung getrennt, aber das kann ein Overkill sein. Dennoch gibt es sie. Vieles 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 die WAR bereitgestellt wird, wird sie explodiert und die Platzhalter werden durch die entsprechenden Werte ersetzt.

Answer 4

Ich empfehle dringend, zusammengestellte Artefakte wie eine War-Datei in der Produktionsumgebung bereitzustellen. Aus diesem Grund verwenden unsere Entwickler das gleiche Build-Skript (in unserem Fall Ant), um das War auf ihrer Entwicklungs-Sandbox zu erstellen, das auch für die Erstellung des endgültigen Artefakts verwendet wird. Auf diese Weise ist es genauso gut zu debuggen wie der Code selbst, ganz zu schweigen von der vollständigen Wiederholbarkeit.

Answer 5

Ich würde mich für den Einsatz einer kontinuierlichen Integrationslösung einsetzen, die verteilte Builds unterstützt. In Ihr SCM eingecheckter Code kann Builds auslösen (für sofortige Tests) und Sie können Builds planen, um Artefakte für die Qualitätssicherung zu erstellen. Diese Artefakte können Sie dann in die Produktion überführen und bereitstellen lassen.

Dies ist, was ich derzeit an der Einrichtung arbeiten, mit AnthillPro .

EDIT: Wir verwenden jetzt Hudson . Sehr zu empfehlen!