Nous développons une grande solution de vente électronique J2EE. Il a beaucoup d'intégrations: CMS, ERP, serveur de messagerie, etc. Tous ces systèmes sont divisés en environnements de test et de production.
Nous devons déployer notre application sur nos serveurs de test avec la configuration de test et lorsqu'il est déployé sur nos serveurs de production, il doit utiliser la configuration de la production. Comment pouvons-nous faire connaître notre application Sélectionnez les propriétés correctes? P>
La chose que nous avons essayée jusqu'à présent est la suivante: p>
Tous nos fichiers de propriétés contiennent des propriétés de test et des propriétés de production P> L'utilisation qui lit ces propriétés a un commutateur: istest () qui préfixe la clé avec "test". p> " est défini par une autre propriété créée par notre serveur de construction. Lorsque le fichier .ear est construit, le script pour nos serveurs de production injecte (entrée à bâtir.xml) "isproduction = true" dans System.properties. P> <propertyfile file="${buildDir}/system.properties">
<entry key="isProduction" value="${systemType}"/>
</propertyfile>
7 Réponses :
Je ne peux pas dire si c'est la meilleure façon, cependant, ce que nous faisons est d'inclure un client client et serveur qui abrite les propriétés en conséquence. Nous incluons ensuite ces pots dans le fichier d'oreille. Donc, au cours de notre processus de construction, nous incluons les pots appropriés (QA, test, PROD) pour l'environnement dans lequel nous déployons.
L'inconvénient est que nous devons gérer trois séries de pots d'environnement et l'équipe de construction doit faire attention à ne pas déployer le problème incorrect. En fait, il est arrivé une fois que nous avions un pot de prod que nous avons déployé sur notre environnement QA et que les données d'assurance qualité ont été mis en production ... Oui, ce qui a sucé et était un gâchis majeur pour nettoyer.
Je regarderai cette discussion parce que je me demande souvent comment nous pouvons rendre ce processus mieux / plus sûr. Super post +1
Vous déployez une oreille? Ensuite, mettez les propriétés nécessaires dans JNDI.
cela pourrait fonctionner. Mais il semble que beaucoup de travaux manuels conservent toutes ces propriétés de synchronisation sur beaucoup de serveurs. Comment allez-vous les contrôler?
Dépend du serveur que vous utilisez. Je crois par exemple JBoss permet de configurer les entrées JNDI en déployant des archives similaires à l'oreille et à la guerre, ce qui vous permet d'utiliser la même procédure que pour votre application principale. Sinon, script IT, et version du script.
De plus, si vous construisez des versions distinctes pour les tests et la production, vous déployez un code non testé en production, car vous avez testé une version différente.
Dans un projet J2EE précédent, nous faisons exactement cela. Le processus de construction (un script ANT) établit les bons fichiers de configuration, les a ajoutés à un certain bocal qui a ensuite été mis dans le fichier d'oreille pour les environnements de production, le test, la formation, l'équité, etc.
Le nom du fichier du fichier d'oreille contenait le nom de l'environnement cible. Il était donc essentiellement impossible de déployer un fichier dans le mauvais environnement. Si nous avons construit pour la cible 156P2 (usine 156, production env. 2), cela ferait partie du nom de fichier du fichier EAR et de la fourmi inclurait config_156p2.xml. Si la cible était incorrecte, le nom du fichier d'oreille serait faux et comme un dernier échec du gars qui l'a déployé remarquerait.
Le fichier de construction devait contenir ceci: une cible d'ant pour démarrer la construction de chaque environnement qui définirait une propriété qui a dit à ANT quel fichier de configuration inclut.
La seule différence entre les fichiers d'oreille serait alors les fichiers de configuration. Tout le reste était identique. Bien entendu, une possibilité que quelqu'un aurait pu écrire une valeur erronée à un fichier de configuration pour un certain environnement. Cependant, dans la pratique, cela n'a jamais eu lieu depuis plusieurs années, même avec de jolis développeurs junior et une quinzaine d'environnements cibles (test différent, QA, formation et serveurs de production dans différents pays).
Ce que vous voulez éviter, c'est avoir le fichier de configuration à l'intérieur de l'oreille, le problème est que vous avez besoin de différentes oreilles pour différents environnements, et modifiant le fichier de configuration nécessite une reconstruction.
Déploie plutôt l'oreille même à chaque serveur, mais configurez chaque serveur avec une ressource d'URL différente. Iow, ajoutez un Ce que j'ai fait (en personnalisant avec le printemps), assurez-vous que JNDI ressource d'URL à tous les serveurs que vous déployez sur ce point sur le fichier de configuration pour cette ressource. Si vous avez lu uniquement l'accès SVN à votre repo, créez les fichiers de configuration sur le repo SVN ou tout repo que vous pouvez accéder via une URL. La chose cool ici est que toute votre configuration est centralisée et la gestion donc est facile.
jndi ressource d'URL en option. Donc, si c'est là, l'application l'utilisera, sinon, ce n'est pas le cas. L'application démarre s'il est là ou non. De cette façon, même lorsqu'il fonctionne avec aucune ressource JNDI disponible, l'application fonctionne toujours (environnement de développement par exemple).
Je vais regarder dans la ressource de l'URL JNDI. Lire la configuration directement à partir de SVN semble bon. Si je comprends cela correctement? Comment gérez-vous les modifications apportées à la configuration? Juste redémarrer l'oreille? Vous avez écrit que vous avez eu une sorte de basculement. Quel est le retour? Config-fichiers à l'oreille?
L'automne retour est des fichiers de configuration à l'oreille. Pour expliquer davantage ... Ceci est la commande Les fichiers de configuration sont chargés 1. Fichier de configuration par défaut 2. Fichier de configuration nommé via un nom d'hôte (nom d'hôte spécifique, également à l'oreille). Vous pouvez donc facilement configurer des applications exécutées sur différents nœuds, par exemple chaque développeur peut configurer son environnement. 3. Le fichier de configuration a regardé via JNDI la dernière valeur chargée est celle utilisée et 2 et 3 sont facultatives. Pour actualiser la configuration, une fois que cela a changé, nous venons de redémarrer l'oreille (car nous utilisons le printemps, les fichiers de configuration sont lus lorsque le contexte de l'application est créé au démarrage).
Nous avons 3 dossiers à cette fin dans nos projets, chacun contient des fichiers de configuration (les noms de fichiers sont identiques entre les dossiers):
Lorsque je construis mon projet, j'ajoute le profil adapté à Intellij Idea Project Build, dans le module désolé, cela signifie essentiellement que j'ajoute un dossier différent de la structure du projet, mais que les noms de fichiers sont les mêmes quels changements ne sont que profil. Propriétés.
Très ancien post répond toujours au cas où quelqu'un le contrôle. Dans chaque serveur d'applications, vous pouvez définir les propriétés du système E.G
Console de gestion Wildfly -> Configuration -> Propriétés du système
- là, j'ajoute une variable
server_environment avec la valeur commedev / uat / prod .Dans mon code Java, j'utilise:
System.getProperty ("Server_Environment")qui me donne la valeur du serveur.
Comme @ Alberto-Zaccagni a déclaré que vous pouvez avoir des dossiers séparés avec des fichiers de propriétés qui n'existent que dans un environnement respectif. Votre code vérifie l'existence d'un dossier commençant par PROD puis UAT puis de dev et quand il trouve un chemin qui existe, il utilise les fichiers de propriétés là-bas.
Les lots ont changé de taille 2009 :) Printemps a maintenant un moyen de le faire dans des profils: docs.spring.io/spring-boot/docs/current/reeference/html/...