Intégration du serveur d'application dans le processus de développement

Question

Aloha,

Je prépare actuellement ma thèse de maîtrise en rédaction d'une application Web interne. Je pars à peu près de zéro. Bien sûr, il y a certaines exigences, mais celles-ci ne sont pas trop importantes pour ma question. Donner la preuve qu'il y aura plus de développement/maintenance quand j'en aurai fini avec la thèse de 4-6 développeurs. Ce que j'ai fait dans les projets/missions précédents consistait à installer le serveur d'applications (AS) à la main (en le configurant, etc.) sur ma machine de développement. Ce que j'ai fait aussi bien est d'utiliser Maven pour installer et configurer quelque chose comme Jetty/Tomcat et les autres développeurs ont juste besoin d'obtenir le projet Maven, lancer mvn install et c'est bon à faire.

Mais que ferez-vous avec un AS comme Wildfly?

Ma question serait: y a-t-il une meilleure pratique pour gérer un AS dans une équipe de 4-6 développeurs? (AS uniquement sur les machines de développement, et non Devevelopment/Qualité/Systèmes de production)

Answer 1

Vous avez 4 options si vous compte tenu de la wildfly comme AS

1. Ajouter votre modification standalone.xml dans votre projet, peut-être dans src/main/resources/ dossier , chaque développeur peut le tirer à travers Git ou quel que soit le VCS que vous utilisez.
2. Vous pouvez créer un script CLI pour un Wildfly et l'inclure de nouveau dans votre base de code. Vous pouvez trouver quelques tutoriel sur internet, par exemple here. L'avantage par rapport à XML est que vous n'avez pas besoin de modifier la source manuellement, le script peut être exécuté en batch, ce qui signifie qu'il va tout configurer correctement ou le laisser intact.
3. Configurez Wildfly via Maven plugin. Vous pouvez exécuter les mêmes commandes que dans l'option 2, un exemple peut être vu here.
4. Vous pouvez également télécharger un ZIP modifié avec votre serveur à un emplacement donné et demander à chaque développeur d'utiliser cette version. L'inconvénient est que tout le monde devra télécharger à nouveau ce fichier ZIP si vous apportez des modifications à la configuration.

Je pense donc que l'option numéro 3 est le meilleur (car il est plus automatisé et il est plus facile de se propager le changement de configuration entre tous les développeurs) mais votre pom.xml peut être vraiment pléthorique avec la configuration. Dans ce cas, vous pouvez le combiner avec l'option numéro 2 afin que le plugin Maven ne fasse que lancer le fichier de script CLI depuis l'intérieur de votre projet.