Responsabilités de Build Script et Build Server

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

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?

version-control continuous-integration builds

— Angelo.Hannes
source

Autant que c'est une bonne question, et on y répondra (je le ferai plus tard quand j'aurai le temps, et cela n'a pas encore été répondu): vous devriez vraiment revenir en arrière et obtenir des éclaircissements de votre conseiller. Être confus après avoir eu une conversation avec quelqu'un qui évaluera vos performances est une recette pour un désastre et une indication qu'ils ne communiquent pas correctement avec vous (ou que vous n'écoutez pas activement, mais cela ne semble pas être le cas ici).

— Steven Evers

@ Angelo.Hannes Je pense que vous avez touché tous les points majeurs. Pouvez-vous clarifier plus précisément ce qui vous déroute?

— M. Dudley

@SteveEvers Eh bien, comme je viens de lire quelques introductions à ce sujet, je voulais d'abord élargir mes connaissances à ce sujet. Je reprendrai alors certainement ce sujet. Par conséquent, j'apprécierais vraiment une réponse de votre part.

— Angelo.Hannes

@ M.Dudley Comme je l'ai dit, je ne sais pas quelles responsabilités vont où. Et si un script de construction pour l'ensemble du logiciel est la bonne solution.

— Angelo.Hannes

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.

— JBRWilkinson
source