Meilleure pratique de Maven pour générer des artefacts pour plusieurs environnements [prod, test, dev] avec le support de CI / Hudson?

J'ai un projet qui doivent être déployées dans des environnements multiples (prod, test, dev). Les principales différences consistent principalement dans les propriétés de configuration/fichiers.

Mon idée était d'utiliser des profils et des superpositions de copier/configurer spécialisées de sortie. Mais je suis coincé dans si je dois générer de multiples artefacts spécialisés dans les classificateurs (ex: "my-app-1.0-prod.zip/jar", "my-app-1.0-dev.zip/jar") ou dois-je créer plusieurs projets, un projet pour chaque environnement ?!
Dois-je utiliser maven-assembly-plugin pour générer de multiples artefacts pour chaque environnement ?
De toute façon, je vais avoir besoin de générer tous à la fois, donc il semble que les profils ne correspondent pas ... toujours perplexe 🙁

Tous les conseils/exemples/lien sera plus que bienvenue.

Comme une question de côté, je me demande aussi comment atteindre cet objectif dans un CI Hudson/Bambou pour générer et déployer ces artefacts produits pour tous les environnements, de leurs propres serveurs (ex: à l'aide de SCP Hudson plugin) ?

source d'informationauteur user68682 | 2010-03-11

  1. 10

    Je préfère les fichiers de configuration de package séparément à partir de l'application. Cela vous permet d'exécuter exactement la même demande et de l'offre de la configuration au moment de l'exécution. Il vous permet également de générer les fichiers de configuration après le fait pour un environnement que vous ne saviez pas que vous auriez besoin au moment de la construction. par exemple, CERT
    J'utilise le "montage" de l'outil de zip de chaque domaine de fichiers de configuration dans les fichiers nommés.

  2. 2

    Je voudrais utiliser le version élément (comme 1.0-SNAPSHOT, 1.0-UAT, 1.0-PROD) et donc tags/branches à la VCS niveau en combinaison avec des profils (pour les environnements choses spécifiques comme les machines de noms, le nom d'utilisateur mots de passe, etc), pour construire les différents artefacts.

  3. 1

    Nous avons mis en place un m2, un plugin pour construire la finale .propriétés à l'aide de l'approche suivante:

    • La commune, de l'environnement n'est pas au courant les paramètres sont lus à partir de la commune.les propriétés.
    • Spécifiques, sensible à l'environnement, les paramètres sont lus à partir de dev.propriétés, test.propriétés ou de production.propriétés, ce qui annule les valeurs par défaut si nécessaire.
    • La finale .les propriétés des fichiers est écrit sur le disque avec les Propriétés de l'instance après avoir lu les fichiers dans l'ordre donné.
    • .fichier de propriétés est ce qui est livré en fonction de l'environnement cible.
  4. 0

    Nous utiliser des profils pour y parvenir, mais nous n'avons que le profil par défaut - que l'on appelle "développement", et a des fichiers de configuration sur elle, et nous avons une "libération" de profil, où nous n'avons pas inclure les fichiers de configuration (afin qu'ils puissent être correctement configuré lors de l'installation de l'application).

    Je voudrais utiliser des profils pour le faire, et je voudrais ajouter le profil dans le nom d'artefact si vous avez besoin de le déployer. Je pense que c'est un peu similaire à ce que Pascal avait suggéré, seulement que vous allez être en utilisant les profils et non des versions.

    PS: une Autre raison pour laquelle nous avons dev/profils de libération seulement, c'est que chaque fois que nous envoyer quelque chose pour l'UAT ou de la PROD, il a été libéré, donc si il y a un bug il est possible de déterminer quel est l'état du code, c'est lorsque l'application est sorti - il est plus facile pour le tag SVN que d'essayer de retrouver son état à partir de la validation de l'histoire.

  5. 0

    J'ai eu exactement ce scénario, l'été dernier.

    J'ai fini par utiliser des profils pour chaque hausse de l'environnement avec des classificateurs. Le profil par défaut est "ne pas nuire", version de développement. J'ai eu un DEV, INT, UAT, l'assurance qualité, et la PROD profil.

    J'ai fini par la définition de plusieurs emplois au sein de l'Hudson pour générer la région spécifique des artefacts.

    La seule chose que j'aurais fait différemment a été à l'architecte les projets un peu différemment, de sorte que la région spécifique de construire a été à l'extérieur de la modularité de projet principal. Qui est il serait, il suffit de tirer dans les derniers artefacts pour chaque build spécifique plutôt que de reconstruire l'ensemble du projet pour chaque région.

    En fait, quand je le programme d'installation de l'emploi, l'assurance de la qualité et de la PROD emplois ont été toujours d'installation pour se développer à partir d'une balise. C'est clairement quelque chose que vous adapter à votre lieu de travail spécifique règles de déploiement.

  6. 0

    Essayez d'utiliser https://github.com/khmarbaise/multienv-maven-plugin pour créer l'un des principaux GUERRE et une configuration JAR pour chaque environnement.