Java Web Deployment: build-Code oder bereitstellen .war?

StackOverflow https://stackoverflow.com/questions/141693

  •  02-07-2019
  •  | 
  •  

Frage

Zwei wichtige Möglichkeiten, um ein J2EE / Java Web App (in einem sehr simplen Sinne) zu implementieren:

Bereitstellen montiert Artefakte Produktion Feld

Hier schaffen wir die .war (oder was auch immer) an anderer Stelle, so konfigurieren, dass für die Produktion und stellen die daraus resultierenden Artefakte auf den Produktionsservern (möglicherweise zahlreiche Artefakte für zahlreiche Kisten zu schaffen).

  • Pros : Keine Entwickler-Tools auf Produktion Boxen können wiederverwenden Artefakte aus direkt zu testen, den Personaleinsatz zu tun braucht keine Kenntnisse der Build-Prozess
  • Cons : zwei Prozesse für die Erstellung und Bereitstellung von Artefakten; potentiell komplexe Konfiguration von vorgefertigten Artefakte könnte Prozess schwer zu Skript machen / automatisieren; müssen Version binäre Artefakte
Bauen

, um die Artefakte auf die Produktion Feld

Hier verwendete der gleiche Prozess von Tag zu Tag zu bauen und lokal auf Entwickler-Boxen einsetzen wird verwendet, um die Produktion zu implementieren.

  • Pros : Ein Verfahren, zu halten; und es ist schwer geprüft / validiert durch den häufigen Gebrauch. Potenziell einfache Konfiguration an Artefakt Erstellungszeit anpassen, anstatt Nachwort vorgefertigten Artefakt anpassen; keine Versionsverwaltung von binären Artefakte benötigt.
  • Cons : Potentiell komplexe Entwicklungs-Tools auf allen Produktions Boxen benötigt werden; Bereitstellung Personal benötigt Build-Prozess zu verstehen; Sie nicht die Bereitstellung, was Sie getestet

Ich habe meistens verwendet das zweite Verfahren, allerdings aus der Not (keine Zeit / Priorität für einen anderen Deployment-Prozess). Persönlich kaufe ich nicht Argumente wie „die Produktion Box sauber von allen Compilern zu sein hat, usw.“, aber ich können sehen die Logik bei der Bereitstellung, was Sie getestet haben (im Gegensatz zu einem anderen Gebäude Artefakt).

Allerdings Java Enterprise Anwendungen sind so empfindlich auf Konfiguration, es fühlt sich an wie für die Nachfrage nach Ärger mit zwei Prozessen Artefakte zu konfigurieren.

Die Gedanken?

Update

Hier ist ein konkretes Beispiel:

Wir verwenden OSCache und den Disk-Cache aktivieren. Die Konfigurationsdatei muss in der WAR-Datei sein, und es verweist auf einen Dateipfad. Dieser Weg unterscheidet sich in jeder Umgebung. Der Build-Prozess erkennt den konfigurierten Standort des Nutzers und stellt sicher, dass die Objekte im Krieg platzierte Datei für seine Umgebung korrekt ist.

Wenn wir den Build-Prozess für die Bereitstellung verwenden, wäre es eine Frage der Schaffung der richtigen Konfiguration für die Produktionsumgebung (z production.build.properties).

Wenn wir die „bereitstellen montiert Artefakte auf die Produktion Box“ folgen, würden wir einen zusätzlichen Prozess müssen die (falsche) OSCache Eigenschaften zu extrahieren und ersetzen sie durch eine entsprechende in der Produktionsumgebung.

Dies erzeugt zwei Prozesse, die gleiche Sache zu erreichen.

Also, die Fragen sind:

  • Ist dies vermeidbar ohne "Kompilieren auf der Produktion"?
  • Wenn nicht, dann ist dies das wert? Es wird der Wert von "no Compilierung auf Produktion" größer als "Do not Repeat Yourself"?
War es hilfreich?

Lösung

Ich bin fest gegen Gebäude auf dem Produktionsfeld, weil es bedeutet, dass Sie einen anderen Build verwenden, als Sie getestet. Es bedeutet auch, jeden Einsatz Maschine eine andere JAR / WAR-Datei hat. Wenn nichts anderes, eine einheitliche Build tut nur so, dass, wenn Bug-Tracking Sie sich nicht um Inkonsistenzen zwischen den Servern kümmern.

Auch Sie brauchen nicht die Builds in der Versionskontrolle zu stellen, wenn Sie einfach zwischen einem Build und der Quelle abbilden können, die es erstellt.

Wo ich arbeite, unser Deployment-Prozess ist wie folgt. (Dies ist unter Linux mit Tomcat).

  1. Test Änderungen und überprüfen Sie in Subversion. (Nicht unbedingt in dieser Reihenfolge, wir brauchen nicht, dass engagierter Code getestet Ich bin der einzige Vollzeit-Entwickler, so dass der SVN Baum im Wesentlichen Zweig meiner Entwicklung ist die Leistung kann variieren...)

  2. Kopieren Sie die JAR / WAR-Dateien auf einen Produktionsserver in einem gemeinsamen Verzeichnis nach der Subversion-Revisionsnummer benannt. Die Webserver haben nur Lesezugriff.

  3. Das Bereitstellungsverzeichnis enthält relativ symbolische Links auf die Dateien in den Revisions genannten Verzeichnisse. Auf diese Weise wird eine Verzeichnisliste zeigt Ihnen immer, welche Version des Quellcodes die laufende Version erzeugt. Bei der Bereitstellung aktualisieren wir eine Protokolldatei, die wenig mehr als eine Verzeichnisliste ist. Das macht Roll-backs einfach. (Ein Gotcha, obwohl; Tomcat prüft, ob neue WAR-Dateien durch das Änderungsdatum der realen Datei, nicht die Symlink, so müssen wir die alte Datei berühren, wenn ein Rollback).

Unsere Webserver entpacken die WAR-Dateien auf einem lokalen Verzeichnis. Der Ansatz ist skalierbar, da das WAR-Dateien auf einem einzelnen Dateiserver sind; konnten wir eine unbegrenzte Anzahl von Web-Servern haben und nur einen einzigen Einsatz tun.

Andere Tipps

Die meisten der Orte, die ich gearbeitet habe die erste Methode mit umgebungsspezifischen Konfigurationsinformationen verwendet haben, separat eingesetzt (und noch viel seltener aktualisiert), die außerhalb des Krieges / Ohr.

ich sehr empfehlen „Deploy montiert Artefakte Produktion Box“ wie ein Krieg Datei. Aus diesem Grunde ist unser Entwickler den gleichen Build-Skript (Ant in unserem Fall) den Krieg auf ihrer Entwicklung Sandbox zu konstruieren, wie es verwendet wird, die schließlich Artefakt zu erstellen. So ist es auch der Code debuggt selbst, nicht vollständig wiederholbar zu erwähnen.

Es gibt Konfigurationsdienste, wie schweres Gewicht ZooKeeper und die meisten Container ermöglichen Sie JNDI verwenden, um einige Konfiguration zu tun. Diese werden getrennt, die die Konfiguration aus dem Build, kann aber zu viel des Guten. Aber es gibt sie. Viel hängt von Ihren Bedürfnissen.

Ich habe auch ein Verfahren, bei dem der Artefakte mit Platzhalter für Konfigurationswerte erstellt werden. Als der Krieg eingesetzt wird, ist es explodiert und die Platzhalter mit den entsprechenden Werten ersetzt.

Ich würde verfechten die Verwendung einer kontinuierlichen Integrationslösung, die baut unterstützt verteilte. Code überprüft in Ihrem SCM auslösen können (für die sofortige Prüfung) baut und Sie können Builds planen Artefakte für QA zu erstellen. Anschließend können Sie diese Artefakte Produktion fördern und haben sie im Einsatz.

Dies ist zur Zeit, was ich auf der Einrichtung arbeite, mit AnthillPro .

EDIT: Wir verwenden nun Hudson . Sehr empfehlen!

Wenn Sie diese Frage in Bezug auf das Konfigurationsmanagement fragen, dann muss die Antwort auf der Grundlage, was Sie als ein verwalteter Artefakt sein. Aus CM Sicht ist es eine inakzeptable Situation eine Sammlung von Quelldateien arbeiten in einer Umgebung und in einem anderen nicht zu haben. CM ist empfindlich gegenüber Umgebungsvariablen, Optimierungseinstellungen, Compiler und Runtime-Versionen usw., und Sie haben für diese Dinge zu berücksichtigen.

Wenn Sie diese Frage in Bezug auf wiederholbare Prozesserstellung fragen, dann muss die Antwort auf die Lage und Menge von Schmerzen beruhen Sie bereit sind zu tolerieren. eine WAR-Datei verwendet, kann mehr Upfront-Schmerz um beinhalten Aufwand in Test- und Bereitstellungszyklen zu speichern. Mit Quelldateien und Build-Tools können Upfront-Kosten sparen, aber Sie werden sich mit Fragen spät in den Bereitstellungsprozess im Umgang zusätzliche Schmerzen ertragen haben.

Update für konkretes Beispiel

Zwei Dinge zu beachten, relativ zu Ihrem Beispiel.

  1. Eine WAR-Datei ist nur eine ZIP-Datei mit einer anderen Erweiterung. Sie könnten die Konfigurationsdatei anstelle mit Standard-ZIP-Utilities ersetzen.

  2. Potenziell die Notwendigkeit, überdenken Sie die Konfigurationsdatei in der WAR-Datei zu setzen. Wäre es genug sein, es auf dem Classpath oder Eigenschaften in der Ausführungsbefehlszeile beim Starten des Servers angegeben haben.

Im Allgemeinen versuche ich, Deployment-Konfiguration spezifische Anforderungen im Hinblick auf die Einsatzstelle zu halten.

Unter Verwendung von 1 verpackt Krieg Dateien für entfalten ist eine gute Praxis.
wir verwenden Ameise, die Werte zu ersetzen, die zwischen Umgebungen unterschiedlich sind. Wir überprüfen Sie die Datei in einer @@@ Variable, die durch unseren Ant-Skript ersetzt wird erhalten. Der Ant-Skript ersetzt das richtige Element in der Datei und aktualisiert dann die WAR-Datei vor dem deploy zu jedem 

<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"/>

ant Um summarize- macht alles und wir verwenden anthill Ameise zu verwalten. Ameise baut die WAR-Datei, ersetzt die Dateipfade, aktualisiert die WAR-Datei, setzt dann an das Ziel environement. Ein Prozess, in der Tat ein Klick auf eine Schaltfläche in anthill.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top