J'ai besoin de clarifications sur les responsabilités du Build Script et du Build Server.
J'ai lu plusieurs articles sur le Net sur l'intégration continue et les builds. Comprenant
- La clé F5 n'est pas un processus de génération
- Le serveur de build: le moniteur cardiaque de votre projet
- Les versions quotidiennes sont votre ami
Et j'ai eu une conversation avec mon conseiller sur le processus de construction de notre logiciel. Parce qu'il est très expérimenté, je fais confiance à ses déclarations, mais je suis resté confus.
Si je comprends bien, d'après mes recherches (et corrigez-moi ici, car c'est ce que je demande), l'idéal devrait être le suivant:
- chaque projet a son script de construction
- ce script construit le projet
- ce script s'assure que les dépendances sont construites précédemment
Comme les dépendances pourraient être un autre projet, avec leur propre script de construction, une hiérarchie arborescente s’accumule. Il peut y avoir un script de construction supérieur qui génère tous les projets et applications.
Cependant, les responsabilités du Build Server sont:
- consultez le référentiel
- déclencher la construction
- tests de déclenchement et autres outils d'assurance qualité
- rendre l'artefact disponible
Cela peut être déclenché manuellement, tous les soirs ou chaque fois que le référentiel change
Les objectifs de mon conseiller sont, si je comprends bien, qu'un script de build est trop rigide et non maintenable (à part le fait qu'il faudrait très longtemps pour en créer un pour notre base de code héritée). Le Build Server doit également conserver les dépendances, par exemple pour utiliser des dépendances plus anciennes lors de leur création. Et en particulier parce Antque c'était le sujet concret, n'est pas capable de construire toutes sortes de technologies différentes qui sont utilisées dans la base de code, et n'est pas en mesure de maintenir les dépendances.
Pouvez-vous préciser les objectifs et clarifier les responsabilités?
la source
Réponses:
Ces choses sont orthogonales:
Le script de génération est le mécanisme qui, lors de l'appel sur l'arborescence source fraîchement extraite, génère une génération complète des cibles et des dépendances requises. Cela peut simplement être «tout faire» si vous avez un makefile, ou une invocation appropriée de MSBuild, Ant, Maven ou Scons. Si vous avez une hiérarchie complexe de dépendances ou de projets associés, votre «script de génération» peut être un fichier de niveau supérieur qui les appelle tour à tour, vérifiant le succès au fur et à mesure.
Le script de construction n'est qu'un script parmi tant d'autres - extraction, génération, test, package - mais vous pourriez avoir un mécanisme tout-en-un contrôlé par des paramètres de ligne de commande - cela dépend de votre environnement.
Le serveur de build , ou plutôt serveur d'intégration continue , est le mécanisme d'automatisation responsable de la planification / déclenchement, de la surveillance et du reporting de la caisse -> build -> test -> package -> stage -> deploy pipeline. Vous pouvez utiliser cron / Task Scheduler si vous n'avez rien de plus sophistiqué à disposition, mais il existe maintenant de nombreux excellents outils tels que Jenkins, Cruise Control, TeamCity, etc.
Il est important que vous puissiez invoquer une build sans utiliser le serveur CI, dans le cas où elle est occupée / hors ligne / inaccessible / autrement indisponible, donc la logique pour obtenir la build / tester / tout ce qui est fait doit être en dehors de la Système CI, mais est invocable par lui, paramétré par branche / type de build / version / architecture, etc.
la source