Java Web Deployment: code de construction ou déployer .war?

Question

Deux méthodes principales pour déployer une application Web J2EE / Java (dans un sens très simpliste):

Déployer les artefacts assemblés dans la boîte de production

Ici, nous créons le .war (ou autre), le configurons pour la production (en créant éventuellement de nombreux artefacts pour de nombreuses boîtes) et plaçons les artefacts résultants sur les serveurs de production.

• Avantages : aucun outil de développement sur les boîtes de production, possibilité de réutiliser directement les artefacts issus des tests, le personnel chargé du déploiement n'a pas besoin de connaissances du processus de construction
• Inconvénients : deux processus de création et de déploiement d'artefacts; La configuration potentiellement complexe d'artefacts prédéfinis pourrait rendre le processus difficile à script / automatiser; avoir à version artefacts binaires

Créez les artefacts sur la zone de production

Ici, le processus utilisé quotidiennement pour créer et déployer localement sur des boîtes de développement est utilisé pour le déploiement en production.

• Avantages : un processus à maintenir; et il est fortement testé / validé par un usage fréquent. Il est potentiellement plus facile de personnaliser la configuration au moment de la création de l'artefact plutôt que de personnaliser le post-texte d'artefact pré-construit pas de versioning des artefacts binaires nécessaires.
• Inconvénients : des outils de développement potentiellement complexes sont nécessaires sur toutes les machines de production; le personnel de déploiement doit comprendre le processus de construction; vous n'utilisez pas ce que vous avez testé

J'ai surtout utilisé le second processus, certes par nécessité (pas de temps / priorité pour un autre processus de déploiement). Personnellement, je n’achète pas d’arguments comme "la boîte de production doit être vierge de tous les compilateurs, etc.", mais je peux voir la logique dans laquelle vous déployez ce que vous avez testé (par opposition à construire un autre artefact).

Cependant, les applications Java Enterprise sont si sensibles à la configuration que vous avez l'impression de poser deux problèmes pour configurer les artefacts.

Pensées?

Mettre à jour

Voici un exemple concret:

Nous utilisons OSCache et activons le cache de disque. Le fichier de configuration doit se trouver dans le fichier .war et faire référence à un chemin de fichier. Ce chemin est différent sur chaque environnement. Le processus de construction détecte l'emplacement configuré de l'utilisateur et garantit que le fichier de propriétés placé dans le fichier war est correct pour son environnement.

Si nous utilisions le processus de génération pour le déploiement, il nous suffirait de créer la bonne configuration pour l'environnement de production (par exemple, production.build.properties ).

Si nous devions suivre le "déploiement d'artefacts assemblés dans la zone de production", nous aurions besoin d'un processus supplémentaire pour extraire les propriétés (incorrectes) d'OSCache et les remplacer par un processus approprié à l'environnement de production.

Cela crée deux processus pour accomplir la même chose.

Les questions sont donc les suivantes:

• Cela peut-il être évité sans "Compiler sur la production"?
• Si non, est-ce que cela en vaut la peine? C’est la valeur de "pas de compilation à la production" supérieur à "Ne vous répétez pas"?

Answer 1

Je suis fermement opposé à la construction sur la boîte de production, car cela signifie que vous utilisez une version différente de celle testée. Cela signifie également que chaque machine de déploiement a un fichier JAR / WAR différent. Si ce n’est rien d’autre, faites une compilation unifiée juste pour que lors du suivi des bogues, vous n’ayez pas à vous soucier des incohérences entre les serveurs.

De plus, vous n'avez pas besoin de mettre les versions en contrôle de version si vous pouvez facilement faire le lien entre une version et la source qui l'a créée.

Où je travaille, notre processus de déploiement est le suivant. (Ceci est sous Linux, avec Tomcat.)

1. Testez les modifications et vérifiez dans Subversion. (Pas nécessairement dans cet ordre; nous n'exigeons pas que le code engagé soit testé. Je suis le seul développeur à temps plein. L'arborescence SVN est donc essentiellement ma branche de développement. Votre kilométrage peut varier.)

2. Copiez les fichiers JAR / WAR sur un serveur de production dans un répertoire partagé nommé d'après le numéro de révision de Subversion. Les serveurs Web ont uniquement un accès en lecture.

3. Le répertoire de déploiement contient des liens symboliques relatifs aux fichiers des répertoires nommés par la révision. Ainsi, une liste de répertoires vous indiquera toujours quelle version du code source a généré la version en cours. Lors du déploiement, nous mettons à jour un fichier journal qui n'est guère plus qu'une liste de répertoires. Cela facilite les retours en arrière. (Cependant, Tomcat vérifie la présence de nouveaux fichiers WAR en fonction de la date de modification du fichier réel, et non du lien symbolique, nous devons donc toucher l'ancien fichier lors de la restauration.)

Nos serveurs Web décompactent les fichiers WAR dans un répertoire local. L'approche est évolutive, car les fichiers WAR se trouvent sur un seul serveur de fichiers. nous pourrions avoir un nombre illimité de serveurs Web et ne faire qu'un seul déploiement.

Answer 2

La plupart des endroits dans lesquels j'ai travaillé ont utilisé la première méthode avec des informations de configuration spécifiques à un environnement déployées séparément (et mises à jour beaucoup plus rarement) en dehors des zones de guerre.

Answer 3

Je vous recommande vivement de "déployer les artefacts assemblés dans la zone de production". comme un fichier de guerre. C'est pourquoi nos développeurs utilisent le même script de construction (Ant dans notre cas) pour construire la guerre sur leur sandbox de développement, de la même manière que pour créer l'artefact finally. De cette façon, il est débogué ainsi que le code lui-même, sans parler de tout à fait répétable.

Answer 4

Il existe des services de configuration, tels que ZooKeeper , et la plupart des conteneurs permettent vous utilisez JNDI pour faire une configuration. Ceux-ci sépareront la configuration de la construction, mais peuvent être excessifs. Cependant, ils existent. Tout dépend de vos besoins.

J'ai également utilisé un processus selon lequel les artefacts sont générés avec des espaces réservés pour les valeurs de configuration. Lorsque le fichier WAR est déployé, il explose et les espaces réservés sont remplacés par les valeurs appropriées.

Answer 5

Je préconiserais l'utilisation d'une solution d'intégration continue prenant en charge les versions distribuées. Le code vérifié dans votre SCM peut déclencher des générations (pour un test immédiat) et vous pouvez planifier des générations pour créer des artefacts pour le contrôle qualité. Vous pouvez ensuite promouvoir la production de ces artefacts et les déployer.

C’est actuellement ce que je travaille actuellement sur la configuration, en utilisant AnthillPro .

EDIT: nous utilisons maintenant Hudson . Je le recommande vivement!

Answer 6

Si vous posez cette question relative à la gestion de la configuration, votre réponse doit être basée sur ce que vous considérez être un artefact géré. Du point de vue de la gestion de contenu, il est inacceptable de disposer d’une collection de fichiers source fonctionnant dans un environnement et non dans un autre. CM est sensible aux variables d’environnement, aux paramètres d’optimisation, aux versions du compilateur et de l’exécution, etc., et vous devez en tenir compte.

Si vous posez cette question relative à la création de processus répétable, la réponse doit être basée sur l'emplacement et la quantité de douleur que vous êtes prêt à tolérer. L'utilisation d'un fichier .war peut entraîner des difficultés supplémentaires afin de vous épargner des efforts lors des cycles de test et de déploiement. L'utilisation de fichiers source et de création d'outils peut réduire les coûts initiaux, mais vous devrez faire face à des difficultés supplémentaires pour traiter les problèmes en retard dans le processus de déploiement.

Mise à jour pour exemple concret

Deux éléments à prendre en compte par rapport à votre exemple.

1. Un fichier .war est simplement un fichier .zip avec une autre extension. Vous pouvez remplacer le fichier de configuration sur place à l'aide des utilitaires de compression standard.

2. Réfléchissez éventuellement à la nécessité de placer le fichier de configuration dans le fichier .war. Serait-il suffisant de l'avoir sur le chemin d'accès aux classes ou de spécifier les propriétés dans la ligne de commande d'exécution au démarrage du serveur.

En règle générale, j'essaie de conserver les exigences de configuration de déploiement spécifiques à l'emplacement de déploiement.

Answer 7

Il est recommandé d’utiliser 1 fichier war empaqueté pour les déploiements.
nous utilisons ant pour remplacer les valeurs différentes entre les environnements. Nous archivons le fichier avec une variable @@@ qui sera remplacée par notre script ant. Le script ant remplace l'élément correct dans le fichier, puis met à jour le fichier war avant le déploiement vers chaque

.

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

En résumé, tout est fait et nous utilisons une fourmilière pour gérer les fourmis. ant construit le fichier war, remplace les chemins de fichier, met à jour le fichier war, puis se déploie dans l'environnement cible. Un processus, en fait, un clic sur un bouton dans une fourmilière.