Comment différencier les propriétés de test et de production dans une application?

Question

Nous développons une grande solution de vente électronique J2ee. Il y 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 une configuration de test et, lorsqu'elle est déployée sur nos serveurs de production, elle doit utiliser la configuration de production. Comment pouvons-nous faire en sorte que notre application sélectionne les bonnes propriétés?

La chose que nous avons essayé est jusqu'à présent:

Tous nos fichiers de propriétés contiennent des propriétés d'essai et les propriétés de production

test.mvxapi.server = SERV100TS 
test.mvxapi.username = user 
test.mvxapi.password = password 
test.mvxapi.port = 6006 
test.mvxapi.cono = 600 

mvxapi.server = SERV10001 
mvxapi.username = user 
mvxapi.password = password 
mvxapi.port = 6001 
mvxapi.cono = 100 

Le Util qui lit ces propriétés a un interrupteur: isTest() qui préfixe la clé avec "test".

public String getProperty(String property) 
{ 
    return properties.getProperty(prefix + "" + property); 
} 

Le commutateur est défini par une autre propriété créée par notre serveur de génération. Lorsque le .EAR est construit, le script de nos serveurs de production injecte (input to build.xml) "isProduction = true" dans system.properties.

<propertyfile file="${buildDir}/system.properties"> 
     <entry key="isProduction" value="${systemType}"/> 
    </propertyfile> 

Je ne suis pas sûr que ce soit la meilleure façon de le faire. Si, pour une raison quelconque, "isProduction = false" est mal engagé dans notre environnement de production, tout l'enfer est libre.

J'ai lu des personnes qui ont des propriétés localement sur le serveur. Mais nous ne voulons vraiment pas que les fichiers soient répartis. Nous avons un cluster de serveurs de production. S'assurer que chaque serveur a le bon fichier de propriétés ne semble pas sûr

Answer 1

Qu'est-ce que vous voulez éviter est d'avoir le fichier de configuration dans l'oreille, le problème est que vous avez besoin différent AER pour les environnements différents, et aussi, de modifier le fichier de configuration nécessite une reconstruction.

Plutôt déployer le même EAR sur chaque serveur, mais configurer chaque serveur avec une ressource URL différente. Ajoutez une ressource URL JNDI à tous les serveurs que vous déployez jusqu'à ce point dans le fichier de configuration de cette ressource. Si vous avez seulement lu l'accès SVN à votre repo, créez les fichiers de configuration sur le repo svn, ou tout repo auquel vous pouvez accéder via une URL. Ce qu'il y a de cool ici, c'est que toute votre configuration est centralisée et donc la gestion est facile.

Ce que je l'ai fait (en personnalisant avec ressort) est de vous assurer que JNDI ressource URL en option. Donc, si c'est là, l'application va l'utiliser, sinon, ce ne sera pas le cas. L'application démarre si elle est là ou non. De cette façon, même en cours d'exécution sans ressources JNDI disponibles, l'application fonctionne toujours (environnement de développement par exemple).

Answer 2

Je ne peux pas dire si c'est le meilleur moyen, cependant, ce que nous faisons est d'inclure un client et un jar serveur qui héberge les propriétés en conséquence. Nous incluons ensuite ces fichiers dans le fichier EAR. Ainsi, au cours de notre processus de construction, nous incluons les jars (QA, TEST, PROD) appropriés pour l'environnement dans lequel nous déployons. L'inconvénient est que nous devons gérer trois ensembles de fichiers d'environnement et que l'équipe de construction doit veiller à ne pas déployer la version incorrecte. En fait, il est arrivé une fois qu'un pot PROD a été déployé dans notre environnement d'assurance qualité et que les données d'assurance qualité commençaient à être mises en production ... oui, c'était nul et c'était un gros gâchis à nettoyer.

Je vais suivre cette discussion parce que je me demande souvent comment nous pouvons améliorer ce processus. Great Post +1

Answer 3

Vous déployez un fichier EAR? Ensuite, mettez les propriétés nécessaires dans JNDI.

Answer 4

Dans un projet J2EE précédent, nous l'avons fait exactement. Le processus de construction (un script ant) ​​a rassemblé les bons fichiers de configuration, les a ajoutés à un certain fichier jar qui a ensuite été placé dans le fichier EAR pour les environnements de production, test, formation, QA, etc

Le nom de fichier du Le fichier EAR contenait le nom de l'environnement cible, il était donc pratiquement impossible de déployer un fichier dans le mauvais environnement. Si nous construisons pour la cible 156p2 (usine 156, production env.2), cela ferait partie du nom de fichier du fichier EAR et la fourmi inclurait config_156p2.xml. Si la cible était incorrecte, le nom du fichier EAR serait erroné et, en tant que dernier élément de sécurité, le type qui le déploierait le remarquerait.

Le fichier de construction devait contenir ceci: une cible ant pour démarrer la construction pour chaque environnement qui définirait une propriété qui indiquerait le fichier de configuration à inclure.

La seule différence entre les fichiers EAR seraient alors les fichiers de configuration. Tout le reste était identique. Bien sûr, il est possible que quelqu'un ait écrit une valeur erronée dans 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 certains développeurs assez jeunes et une quinzaine d'environnements cibles (différents tests, QA, serveurs de formation et de production dans différents pays).

Answer 5

Nous avons 3 dossiers à cet effet dans nos projets, chacun contient les fichiers de configuration (noms de fichiers sont les mêmes entre les dossiers):

personnelle
• : contient les chemins pour tester db, serveur, etc
• test: contient des chemins vers les serveurs partagés avec mes collègues
• production: contient ... et bien vous l'aurez deviné

Quand je construis mon projet, j'ajouter le profil adapté à Intellij Id ea construction de projet, dans le module desidered, cela signifie essentiellement que je suis en ajoutant un autre dossier à la structure du projet, mais parce que les noms de fichiers sont les mêmes quels sont les changements que les propriétés de profil.