Constructions nocturnes : Pourquoi devrais-je le faire ?

Question

Pourquoi devrais-je faire Constructions nocturnes ?

Answer 1

Vous devriez faire des constructions nocturnes pour vous assurer que votre base de code reste saine.

Un effet secondaire de faire des constructions nocturnes est que cela oblige l'équipe à créer et à maintenir une construction script entièrement automatisée. Cela permet de s'assurer que votre processus de build est documenté et reproductible.

Les constructions automatisées sont efficaces pour détecter les problèmes suivants :

• Quelqu'un a enregistré un truc qui casse des trucs.
• Quelqu'un a oublié d'enregistrer un fichier ou un changement nécessaire.
• Vos scripts de construction ne fonctionnent plus.
• Votre machine à construire est cassée.

En effectuant cette opération chaque nuit, vous êtes sûr de détecter ces problèmes dans les 24 heures suivant leur apparition. C'est préférable que de trouver tous les problèmes 24 heures avant que vous ne soyez censé livrer le logiciel.

Vous devriez aussi, bien sûr, avoir des tests unitaires automatisés qui sont exécutés pour chaque construction nocturne.

Answer 2

J'ai personnellement trouvé que l'intégration continue était meilleure que les constructions nocturnes :
http://en.wikipedia.org/wiki/Continuous_integration

Je l'utilise même sur les projets d'une seule personne, c'est incroyable la rapidité avec laquelle vous pouvez exposer les problèmes et les régler sur place.

Answer 3

Je fais de l'ingénierie de construction (entre autres choses) depuis 16 ans. Je suis un fervent partisan de la construction précoce, de la construction fréquente et de l'intégration continue. Ainsi, la première chose que je fais avec un projet est d'établir comment il sera construit (Java : Fourmi o Maven .NET : NAnt o MSBuild ) et comment il sera géré ( Subversion ou un autre contrôle de version). Ensuite, je vais ajouter l'intégration continue ( Régulateur de vitesse o CruiseControl.NET ) en fonction de la plate-forme, puis laisser les autres développeurs se débrouiller.

Au fur et à mesure que le projet se développe, et que le besoin de rapports et de documentation augmente, les builds finiront par prendre plus de temps à exécuter. À ce moment-là, je diviserai les builds en builds continus (exécutés lors du checkin) qui compilent et exécutent uniquement les tests unitaires et en builds quotidiens qui construisent tout, exécutent tous les rapports et construisent toute documentation générée. Je peux également ajouter un build de livraison qui marque le référentiel et effectue tout conditionnement supplémentaire pour la livraison au client. J'utiliserai des cibles de construction à grain fin pour gérer les détails, de sorte que tout développeur puisse construire n'importe quelle partie du système - le serveur d'intégration continue utilise exactement les mêmes étapes de construction que tout développeur. Plus important encore, nous ne livrons jamais un build pour les tests ou un client qui n'a pas été construit à l'aide du serveur de build.

C'est ce que je fais - voici pourquoi je le fais (et pourquoi vous devriez le faire aussi) :

Supposons que vous ayez une application typique, avec plusieurs projets et plusieurs développeurs. Bien que les développeurs puissent commencer avec un environnement de développement commun et cohérent (même système d'exploitation, mêmes correctifs, mêmes outils, mêmes compilateurs), au fil du temps, leurs environnements vont diverger. Certains développeurs appliqueront religieusement tous les correctifs et mises à jour de sécurité, d'autres non. Certains développeurs ajouteront de nouveaux outils (peut-être meilleurs), d'autres non. Certains penseront à mettre à jour l'ensemble de leur espace de travail avant de construire, d'autres ne mettront à jour que la partie du projet qu'ils développent. Certains développeurs ajouteront du code source et des fichiers de données au projet, mais oublieront de les ajouter au contrôle de source. D'autres écrivent des tests unitaires qui dépendent des particularités de leur environnement. En conséquence, vous verrez rapidement apparaître les excuses toujours populaires du type "Eh bien, ça se construit/travaille sur ma machine".

En ayant un serveur distinct, stable, cohérent et connu pour la construction de votre application, vous découvrirez facilement ce genre de problèmes, et en exécutant des constructions à partir de chaque livraison, vous serez en mesure d'identifier le moment où un problème s'est glissé dans le système. Plus important encore, comme vous utilisez un serveur distinct pour construire et empaqueter votre application, tout sera toujours empaqueté de la même manière, à chaque fois. Il n'y a rien de pire que de voir un développeur envoyer une version personnalisée à un client, que celle-ci fonctionne et qu'il ne sache pas comment reproduire les personnalisations.

Answer 4

En fait, vous n'en avez pas besoin, ce que vous devriez vouloir, c'est une intégration continue et des tests automatiques (ce qui est un pas de plus que les constructions nocturnes).

Si vous avez le moindre doute, vous devriez lire cet article de Martin Fowler sur l'intégration continue .

En résumé, vous devez construire et tester le plus tôt et le plus souvent possible afin de repérer immédiatement les erreurs et de les corriger pendant que vous avez encore à l'esprit ce que vous vouliez obtenir en les provoquant.

Answer 5

Je recommanderais en fait de faire des constructions à chaque fois que vous vous enregistrez. En d'autres termes, je vous recommande de mettre en place un système d'intégration continue.

Les avantages d'un tel système et d'autres détails peuvent être trouvés dans l'article de Fowler y sur l'entrée Wikipedia entre autres.

Selon mon expérience personnelle, c'est une question de contrôle de la qualité : chaque fois que le code (ou les tests, qui peuvent être considérés comme une forme d'exigences) est modifié, des bogues peuvent se glisser. Pour assurer la qualité, vous devez faire une nouvelle construction du produit tel qu'il sera livré et effectuer tous les tests disponibles. Plus cette opération est fréquente, moins les bogues sont susceptibles de former une colonie. Il est donc préférable d'effectuer des cycles quotidiens (nocturnes) ou continus.

En outre, que vous limitiez l'accès à votre projet aux développeurs ou à un groupe plus important d'utilisateurs, une construction nocturne permet à chacun de disposer de la "dernière version", ce qui minimise la difficulté de réintégrer ses propres contributions dans le code.