J'ai besoin d'aide pour la philosophie et la conception d'une configuration d'intégration continue.
Notre configuration CI actuelle utilise buildbot. Quand j'ai commencé à le concevoir, j'ai hérité (enfin, pas strictement, car j'ai été impliqué dans sa conception un an plus tôt) un constructeur de CI sur mesure qui a été conçu pour exécuter la construction entière en une seule fois, du jour au lendemain. Après un certain temps, nous avons décidé que cela était insuffisant et avons commencé à explorer différents cadres CI, en choisissant finalement buildbot. L'un de mes objectifs lors de la transition vers buildbot (en plus de profiter de tous les extras whiz-bang) était de surmonter certaines des insuffisances de notre constructeur nocturne sur mesure.
Humourez-moi un instant et laissez-moi vous expliquer ce dont j'ai hérité. La base de code de mon entreprise est constituée de près de 150 applications Windows c ++ uniques, chacune ayant des dépendances sur une ou plusieurs d'une douzaine de bibliothèques internes (et beaucoup sur des bibliothèques tierces également). Certaines de ces bibliothèques sont interdépendantes et ont des applications dépendantes qui (alors qu'elles n'ont rien à voir les unes avec les autres) doivent être construites avec la même version de cette bibliothèque. La moitié de ces applications et bibliothèques sont considérées comme "héritées" et non transférables, et doivent être construites avec plusieurs configurations distinctes du compilateur IBM (pour lesquelles j'ai écrit des sous-classes uniques de Compile
), et l'autre moitié est construite avec Visual Studio.ShellCommand
s, car il n'y a pas de support pour VSS).
Notre constructeur nocturne original a simplement pris la source de tout et construit des trucs dans un certain ordre. Il n'y avait aucun moyen de créer une seule application, de choisir une révision ou de regrouper des choses. Il lancerait des machines virtuelles pour créer un certain nombre d'applications. Ce n'était pas très robuste, ce n'était pas distribuable. Ce n'était pas terriblement extensible. Je voulais pouvoir surmonter toutes ces limitations dans buildbot.
La façon dont je l'ai fait à l'origine était de créer des entrées pour chacune des applications que nous voulions créer (toutes les 150), puis de créer des planificateurs déclenchés qui pouvaient créer diverses applications en tant que groupes, puis subsumer ces groupes sous un planificateur de construction nocturne global. Ceux-ci pouvaient fonctionner sur des esclaves dédiés (plus de chicane de machine virtuelle), et si je le voulais, je pourrais simplement ajouter de nouveaux esclaves. Maintenant, si nous voulons faire une construction complète en dehors du calendrier, c'est un clic, mais nous pouvons également créer une seule application si nous le désirons.
Cependant, cette approche présente quatre faiblesses. L'un est le réseau complexe de dépendances de notre arbre source. Afin de simplifier la maintenance de la configuration, tous les générateurs sont générés à partir d'un grand dictionnaire. Les dépendances sont récupérées et construites d'une manière pas terriblement robuste (à savoir, la désactivation de certaines choses dans mon dictionnaire cible de génération). La seconde est que chaque build a entre 15 et 21 étapes de build, ce qui est difficile à parcourir et à regarder dans l'interface Web, et comme il y a environ 150 colonnes, le chargement prend une éternité (pensez de 30 secondes à plusieurs minutes). Troisièmement, nous n'avons plus de découverte automatique des cibles de construction (bien que, autant qu'un de mes collègues me harpe à ce sujet, je ne vois pas ce que cela nous a apporté en premier lieu). Finalement,
Maintenant, en passant à un nouveau développement, nous commençons à utiliser g ++ et subversion (ne pas porter l'ancien dépôt, attention - juste pour les nouveaux trucs). De plus, nous commençons à faire plus de tests unitaires ("plus" pourrait donner la mauvaise image ... c'est plus comme tout ), et les tests d'intégration (en utilisant python). J'ai du mal à trouver comment les intégrer dans ma configuration existante.
Alors, où me suis-je trompé philosophiquement ici? Comment puis-je avancer (avec buildbot - c'est la seule pièce du puzzle sur laquelle j'ai une licence pour travailler) afin que ma configuration soit réellement maintenable? Comment puis-je corriger certaines des faiblesses de ma conception? Qu'est-ce qui fonctionne vraiment en termes de stratégies de CI pour des bases de code volumineuses (peut-être trop) complexes?
ÉDITER:
Je pensais avoir expliqué mon problème, mais évidemment je n'étais pas assez clair. Je ne cherche pas de suggestions pour changer les plateformes CI. Cela ne va pas se produire, et les réponses suggérant que cela ne sera pas accepté. Ce que je veux savoir, c'est comment d'autres personnes gèrent des bases de code complexes en utilisant CI. J'ai une douzaine de produits différents au carré , et j'ai des dépendances dispersées au vent, et elles sont toutes différentes. C'est ce que je veux savoir comment gérer.