Pendant mes années de programmation Java et plus récemment Scala, je n'ai jamais utilisé Ant, Maven, Gradle ou l'un de ces outils de construction pour Java. Partout où j'ai travaillé, il y avait un gestionnaire de build qui s'est occupé de tout cela - je compilais localement avec l'IDE pour le développement et les tests unitaires, puis j'archivais le code source et j'informais le manager de build qui faisait ce qui était nécessaire pour compiler les fichiers de tout le monde pour l'environnement partagé.

Maintenant que je suis entre deux contrats, je travaille sur mon propre projet autofinancé et il arrive au point où il pourrait être assez bon pour gagner de l'argent. J'ai même un investisseur potentiel aligné et je prévois de leur montrer une version bêta dans les prochaines semaines.

Mais tout au long, je clique simplement sur le bouton de construction sur l'IDE, et cela crée le fichier Jar et cela fonctionne très bien. Bien sûr, la sagesse conventionnelle suggère que je "devrais" écrire mes propres scripts Ant / Maven / Gradle et les utiliser à la place de l'IDE, mais quels sont les avantages concrets de cela dans ma situation (travailler seul)?

J'ai fait quelques lectures sur la façon d'utiliser ces outils de construction, et il semblerait que j'écrirais des centaines de lignes de XML (ou Groovy ou autre) pour faire ce que l'IDE fait en un clic (l'IDE généré Ant XML pour le projet est de plus de 700 lignes). Il semble juste sujet aux erreurs et prend du temps et inutile pour ma situation. Sans parler de la courbe d'apprentissage, qui prendrait du temps à tous les autres travaux que je fais pour préparer le produit à montrer aux gens.

Je vous suggère de chercher à utiliser Maven plutôt que Ant. Si votre IDE peut créer votre projet en un seul clic, il est probable que Maven puisse également créer votre projet sans pratiquement aucune configuration personnalisée.

Et pour répondre à la question, la simplification du processus de déploiement en est un exemple concret. Si vous construisez un distribuable localement, cela signifie que vous devez déployer manuellement ce distribuable sur votre système de production, et implique que vous avez probablement dû faire un peu de configuration manuelle sur le système de production pour le préparer pour le déploiement (installation de Tomcat , ou en copiant les dépendances et les ressources requises par votre application). Cela peut prendre du temps et faire du déploiement des mises à jour un processus manuel fastidieux. Il permet également que des différences de configuration mineures entre votre plate-forme de production et votre environnement de développement provoquent des erreurs obscures et difficiles à localiser.

Donc, de toute façon, ce que je fais pour me débarrasser de cette corvée manuelle, c'est que je configure mon projet pour construire avec Maven, et je configure mon pom.xmlfichier avec toutes les informations nécessaires pour (dans le cas d'une application Web Java) trouver et télécharger le version correcte de Tomcat, installez-le localement, configurez les fichiers de configuration Tomcat appropriés, déployez toutes les dépendances du projet et le fichier WAR du projet lui-même, puis démarrez Tomcat. Je crée ensuite un simple script shell (et aussi une .batversion pour Windows) qui utilise Maven pour construire et démarrer le serveur:

mvn clean install cargo:start -Dcargo.maven.wait=true

Donc, au lieu d'emballer un déployable sur mon environnement de développement et de le pousser manuellement jusqu'à la production, tout ce que j'ai à faire est de synchroniser du système de contrôle de version sur le serveur de production, puis le système de production lui-même construit, installe et s'exécute le déployable (et le fait d'une manière identique à la façon dont cela se fait sur n'importe quel système de développement, en minimisant la possibilité d'erreurs spécifiques à la plate-forme ou de mauvaises configurations). Et que ce soit dans l'environnement de développement ou de production, tout ce que je fais pour créer et démarrer le serveur est:

./startServer.sh #or startServer.bat for Windows

Et pour déployer une mise à jour de l'environnement de production, le processus est juste:

1. Arrêtez l'instance de serveur en cours d'exécution, le cas échéant.
2. Courez svn update -r<target_release_revision>.
3. Courez ./startServer.sh.

C'est simple, facile à retenir, et pas du tout possible si je devais compter sur l'utilisation de mon IDE pour construire le déployable pour moi. Cela permet également de revenir au dernier bon déploiement connu en un clin d'œil, si jamais un retour en arrière était nécessaire.

Je ne peux même pas compter le temps que cette approche m'a épargné par rapport à la tentative de gérer manuellement le processus de déploiement et de configuration.

Et bien sûr, une autre réponse à votre question est la gestion automatique des dépendances, mais je pense que cela a déjà été couvert par d'autres réponses.

Tant que votre code est en contrôle de code source, l'utilisation de l'IDE pour rendre vos distributables est très bien.

En tant qu'entreprise individuelle, est-il préférable de passer du temps à ajouter de nouvelles fonctionnalités à votre produit ou à écrire des scripts de construction? Quelque chose me dit qu'il n'écrit pas de scripts de construction.

Bien sûr, il est plus difficile de voir les avantages lorsque vous travaillez seul. Personnellement, j'ai travaillé sur de nombreux projets solo et non seulement j'écrirais un script de construction, mais j'aurais aussi du mal à configurer un serveur CI (comme Jenkins).

Il y a des frais généraux bien sûr, pourquoi cela en vaut-il la peine?

• Une version reproductible, non liée à l'IDE (ou à votre machine, si vous l'exécutez en externe). Si un serveur de build l'exécute, d'autres machines peuvent l'exécuter.
• Le plaisir commence après la construction et les tests unitaires (au fait: êtes-vous sûr de tester avant chaque commit? J'oublie parfois). Générez de la documentation, construisez des programmes d'installation, exécutez vos outils d'analyse de code préférés.
• Votre serveur CI préféré vous permet de voir des graphiques de couverture de code, d'échecs de tests unitaires, etc. au fil du temps. Votre IDE fait-il cela?

Pour mon projet actuel, le script crée, exécute des outils d'analyse statique, compresse js / css, des tests unitaires et des packages dans une archive Web. Jenkins l'exécute après chaque validation et déploie le projet sur un serveur de test.

J'ai pris le temps de mettre cela en place (le script de construction fait peut - être 300 lignes d'ailleurs, je ne l'ai pas touché depuis des mois) et je peux dire que ça vaut le coup, même pour une seule personne. Pour plus d'une personne, c'est nécessaire. Mon implication dans le processus de construction / déploiement consiste en les commandes «hg commit» et «hg push».

Avantages des outils de construction

C'est un bref résumé montrant juste la pointe de l'iceberg, et vous ne remarquerez pas nécessairement l'importance de tout cela, sauf si vous avez besoin de combiner de nombreux projets, de grands projets et une équipe de moyenne à grande. Mais si vous avez la foi et essayez, vous en récolterez les bénéfices .

Ils facilitent le cycle de vie de votre développement et vous permettent de:

• organiser et structurer vos projets de manière cohérente et sans effort
• réutiliser les bonnes pratiques dans tous les projets et les lancer facilement et rapidement ,
• intégrer plusieurs projets dans une même build,
• automatiser votre processus d' intégration continue ,
• partagez votre projet avec les autres
  • sans les obliger à utiliser une boîte à outils ou un IDE spécifique (en dehors du système de build),
  • et sans les surprendre car ils s’attendront à une construction standard
• automatiser et faciliter la maintenance de votre produit
• automatiser le processus de sortie de votre produit

Si nous appliquons cela à Maven ...

Pour ceux d'entre vous dans le monde Java et qui utilisent Maven , en lisant ceci, vous avez naturellement associé chaque point à:

• Convention de projet structuré de Maven
• Archétypes Maven
• Matérialiser un projet à partir de SCM et de constructions de réacteurs
• Jenkins / Hudson / Bamboo / autre support + le support de Maven pour les pratiques de test d'intégration
• m2eclipse, prise en charge native d'IntelliJ ou de NetBeans - ou mvnsh pour la ligne de commande
• versions-maven-plugin
• maven-release-plugin, buildnumber-maven-plugin plugin et versions-maven-plugin

Et bien sûr, Maven (mais d'autres outils également) vous offre une gestion des dépendances , et c'est un énorme gain de temps et d'espace pour vous (compte tenu du nombre de personnes dans votre équipe) et de votre SCM.

Tout est relatif:

J'utilise Maven comme exemple parce que je pense que c'est le système de construction le plus complet et les "batteries incluses", mais cela ne signifie pas que c'est nécessairement le "meilleur". Il convient à toutes les cases à cocher énumérées ci-dessus cependant, et lorsque vous recherchez un bon système de construction, je le compare à cette liste et à Maven. Cependant, Maven n'est pas toujours très flexible - il est cependant très extensible - si vous vous écartez de votre processus standardisé. Il stimule votre productivité dans le cas général (une fois en avance sur la courbe d'apprentissage), pas si vous le combattez.

Voici mes 4 principales raisons d'utiliser les outils de génération:

• gestion des dépendances (éviter les erreurs)
• test (votre modification n'a pas cassé les autres modules - beaucoup plus facile à tester)
• engagements sûrs
• plus facile à déployer local distribuable (personne n'a le temps dans QA env d'attendre que le constructeur construise votre projet et ses dépendances)

Dans le livre Pragmatic Programmer , Andrew Hunt et David Thomas disent que «checkout-build-test-deploy» devrait être une commande unique (Chapitre: Projets Pragmatiques). Tu as écrit..

J'ai même un investisseur potentiel aligné et je prévois de leur montrer une version bêta dans les prochaines semaines

Ensuite, je suis sûr que votre équipe va grandir. Il est encore plus important de faire effectuer des tests automatiques de déploiement.

Le gros XML (script) que vous avez vu est généralement un travail ponctuel. La plupart du temps, les mêmes scripts peuvent être utilisés dans de nombreux projets.

La taille du projet n'est pas claire. Si vos tests / tests d'acceptation intégrés nécessitent un processeur / une mémoire volumineux, vous pouvez envisager d'utiliser une autre machine comme serveur de test. Vous pouvez également déployer une multitude d'outils pour analyser le code source / code octet .

Je dirais que, pour un développeur isolé, avoir un bon processus et une bonne structure comme les builds scriptés est beaucoup plus important que lorsque vous faites partie d'une équipe. La raison en est que vous n'avez pas de coéquipiers pour vous appeler lorsque vous coupez les coins. Un serveur CI exécutant votre script de construction constitue un excellent coéquipier intransigeant pour vous garder honnête.

À mesure que votre base de code grandit, vous souhaiterez ajouter une suite de tests. D'après mon expérience, cela devrait être fait le plus tôt possible et que votre build nocturne (ou autre) devrait exécuter tous les tests à chaque fois. Commencez petit, le XML généré automatiquement est probablement correct. Lorsque vous avez peur de changer quelque chose de peur de casser quelque chose d'autre, c'est une bonne incitation à rédiger quelques cas de test.

Une version non IDE facilite la reconstruction des anciennes versions sans se soucier de reconfigurer votre IDE tel qu'il était à l'époque, vous permet d'effectuer la génération de manière non interactive afin que vous puissiez maintenir une version nocturne pour les personnes à tester ou découvrir rapidement si vous avez réussi les tests sans avoir à vous souvenir de les exécuter et d'attendre qu'ils se terminent.

Il vous permet également d'effectuer des builds dans des environnements non-GUI, par exemple, ssh'ing vers un serveur, et vous permet de changer d'IDE sans vous soucier de perdre la possibilité de construire votre logiciel.

Certains outils de construction vous aident à automatiser le balisage et le déploiement des versions, avec des valeurs par défaut décentes pour générer des rapports de couverture de code, etc.

Lorsque vous ajoutez plus de personnes, un outil de construction s'assurera que vous n'êtes pas vulnérable à la mauvaise configuration IDE de quelqu'un d'autre. Je fais régulièrement des partages d'écran pour corriger les installations Eclipse de mes collègues car ils n'utilisent pas d'outils de construction (en travaillant dessus).

La raison ultime est cependant que c'est quelque chose qui n'a pas besoin d'être fait manuellement, alors ne le faites pas manuellement. Tout le reste en ressort.