Comment gérez-vous les applications Web java dans différents environnements de transfert?

Question

Vous pouvez utiliser un ensemble de propriétés utilisées sur la machine de développement, qui varie d’un développeur à l’autre, un autre ensemble pour un environnement de transfert et un autre pour l’environnement de production.

Dans une application Spring, vous pouvez également avoir des beans que vous souhaitez charger dans un environnement local mais pas dans un environnement de production, et inversement.

Comment gérez-vous cela? Utilisez-vous des fichiers séparés, un filtrage des ressources ant / maven ou d’autres méthodes?

Answer 1

Je viens de mettre les différentes propriétés dans JNDI. De cette façon, chacun des serveurs peut être configuré et je peux avoir UN seul fichier war. Si la liste des propriétés est longue, j'hébergerai les fichiers de propriétés (ou XML) sur un autre serveur. J'utiliserai JNDI pour spécifier l'URL du fichier à utiliser.

Si vous créez différents fichiers d'application (war / ear) pour chaque environnement, vous ne déployez pas la même guerre / oreille que celle que vous testez.

Dans l'une de mes applications, nous utilisons plusieurs services REST. Je viens de mettre l'URL racine dans JNDI. Ensuite, dans chaque environnement, le serveur peut être configuré pour communiquer avec le service REST approprié pour cet environnement.

Answer 2

J'utilise simplement différents fichiers de configuration XML Spring pour chaque ordinateur et veillez à ce que tous les bits de données de configuration qui varient entre les ordinateurs soient référencés par des beans chargés à partir de ces fichiers de configuration Spring.

Par exemple, j'ai une application Web qui se connecte à une interface Java RMI d'une autre application. Mon application obtient l'adresse de l'interface RMI de cette autre application via un bean configuré dans le fichier de configuration Spring XML. Mon application et l'autre ont des instances de développement, de test et de production. Par conséquent, j'ai trois fichiers de configuration pour mon application, l'un correspondant à la configuration appropriée pour l'instance de production, l'autre pour l'instance de test et l'autre pour le dev. exemple.

Ensuite, la seule chose que je dois garder nette est de savoir quel fichier de configuration est déployé sur quelle machine. Jusqu'à présent, la stratégie de création de tâches Ant gérant la copie du fichier de configuration correct avant la création de mon fichier WAR ne me posait aucun problème. Ainsi, dans l'exemple ci-dessus, j'ai trois tâches Ant, une qui génère le fichier WAR de production, une qui génère le fichier dev de développement et une autre qui génère le fichier WAR de test. Les trois tâches gèrent la copie du bon fichier de configuration au bon endroit, puis appellent la même étape suivante, qui consiste à compiler l'application et à créer le fichier WAR.

J'espère que cela a du sens ...

Answer 3

Nous utilisons des fichiers de propriétés spécifiques aux environnements et demandons à ant build de sélectionner le jeu correct lors de la création des fichiers jars / wars.

Les éléments spécifiques à l'environnement peuvent également être gérés via le service d'annuaire (JNDI), en fonction de votre serveur d'applications. Nous utilisons tomcat et notre source de données est définie dans l'implémentation JNDI en lecture seule de Tomcat. Le printemps rend la recherche très facile.

Nous utilisons également la stratégie ant pour créer différents sites (contenu différent, rôles de sécurité, etc.) à partir du même projet source.

Il y a une chose qui nous cause un peu de problème avec cette stratégie de construction: c'est souvent que les fichiers et les répertoires n'existent pas jusqu'à ce que la construction soit exécutée. même configuration que lorsqu’il est déployé) pouvant être exécutés à partir de l’EDI. Vous manquez également une partie de la capacité de l'EDI à vérifier l'existence de fichiers, etc.

Answer 4

J'utilise Maven pour filtrer les ressources sous src / main / resources dans mon projet. J'utilise ceci en combinaison avec des fichiers de propriétés pour extraire des attributs personnalisés dans mes projets Spring.

Pour les versions par défaut, j'ai un fichier de propriétés dans mon répertoire personnel que Maven utilise ensuite comme substitutions (pour que des éléments tels que l'installation locale de Tomcat soient trouvés correctement). Le serveur de test et le serveur de production sont mes autres profils. Un simple -Production suffit ensuite à la création d'une application pour mon serveur de production.

Answer 5

Utilisez différents fichiers de propriétés et utilisez les filtres ant-remplacer qui effectueront le remplacement en fonction de l'environnement pour lequel la génération est effectuée. Voir http: //www.devrecipes. com / 2009/08/14 / configuration spécifique à l'environnement pour les applications java /

Answer 6

Séparez les fichiers de configuration, stockés dans le référentiel de contrôle de source et mis à jour manuellement. En règle générale, la configuration ne change pas radicalement d’une version à l’autre; la synchronisation (même manuelle) n’est donc pas un problème majeur.

Pour les systèmes hautement évolutifs dans les environnements de production, je recommanderais sérieusement un schéma dans lequel les fichiers de configuration sont conservés dans des modèles, et utilisés dans le script de construction, ces modèles sont utilisés pour le rendu "final". fichiers de configuration (tous les environnements doivent utiliser le même processus).

Answer 7

J'ai également récemment utilisé Maven pour des configurations alternatives pour les environnements en direct ou intermédiaires. Configuration de la production à l'aide de Profils Maven . J'espère que ça aide.

Answer 8

J'utilise la copie de Ant avec un fichier de filtre. Dans le répertoire avec le fichier de configuration avec les variables, j'ai un répertoire avec un fichier pour chaque environnement. Le script de génération connaît l'environnement et utilise le fichier de variable correct.

Answer 9

J'ai différents dossiers de configuration contenant les configurations pour le déploiement cible et j'utilise ANT pour sélectionner celui à utiliser lors de l'étape de copie de fichier.

Answer 10

Nous utilisons différentes cibles de fourmis pour différents environnements. Notre façon de faire est peut-être un peu inélégante, mais cela fonctionne. Nous allons simplement indiquer à certaines cibles ant de filtrer différents fichiers de ressources (ce qui permet d'empêcher le chargement de certains beans), de charger différentes propriétés de base de données et de charger différentes données de base dans la base de données. Nous n'avons pas vraiment d'expert en fourmi, mais nous sommes en mesure d'exécuter nos versions avec différentes configurations à partir d'une seule commande.

Answer 11

Une solution que j’ai vue utilisée consiste à configurer l’environnement de transfert de manière à ce qu’il soit identique à l’environnement de production. Cela signifie que chaque environnement a un VLAN avec la même plage IP et des rôles d'ordinateur sur les mêmes adresses IP (par exemple, l'adresse IP du cluster de base de données est toujours 192.168.1.101 dans chaque environnement). Les pare-feu ont mappé des adresses externes sur les serveurs Web. Ainsi, en échangeant les fichiers hôte sur votre PC, vous pouvez utiliser la même URL - http://www.myapp.com/webapp/file.jsp passe en mode de stockage intermédiaire ou en mode de production, en fonction du fichier d'hôtes que vous avez remplacé.

Je ne suis pas sûr que ce soit une solution idéale, il est très difficile à maintenir, mais c'est une solution intéressante à noter.

Answer 12

Caleb P et JeeBee ont probablement votre solution la plus rapide. De plus, vous n'avez pas à configurer différents services ni à pointer des fichiers sur des ordinateurs différents. Vous pouvez spécifier votre environnement en utilisant une variable $ {user.name} ou en spécifiant le profil dans un argument -D pour Ant ou Maven.

De plus, dans cette configuration, vous pouvez avoir un fichier de propriétés générique et remplacer les fichiers de propriétés pour des environnements spécifiques. Ant et Maven prennent en charge ces fonctionnalités.

Answer 13

N'oubliez pas d'enquêter sur PropertyPlaceholderConfigurer - cela est particulièrement utile dans les environnements où JNDI n'est pas disponible