Comment est organisée l'intégration continue dans les grandes entreprises?

Dans mon entreprise, il est courant de ne pas faire de build intermédiaire pour vérifier comment chaque branche fonctionnalité / correction de bug est fusionnée dans dev. Il n'y a qu'une version quotidienne, ce qui provoque toujours beaucoup d'échecs de test et d'erreurs de génération. On m'a dit qu'il n'était pas raisonnable de construire pour chaque fusion pour plus de 1000 développeurs.

J'ai donc cherché comment CI est organisé dans les entreprises qui ont autant de développeurs ou plus (Microsoft, Facebook), et je n'ai rien trouvé. Peut-être que les initiés pourront me le dire alors?

Il s'agit essentiellement d'un problème de mise à l'échelle. Vous séparez votre travail en modules, qui peuvent être différents projets et / ou différentes fonctionnalités de votre produit.

Vous auriez des équipes qui couvrent des ensembles de ces modules. Chacune de ces équipes aurait des cycles de CI configurés pour leurs étendues, et seulement après que leurs cycles respectifs seraient passés, le code serait poussé vers les référentiels principaux, où le cycle de CI maître serait exécuté.

Le cycle CI maître sera très probablement différent des cycles CI de niveau équipe sur ces aspects:

• Les cycles CI au niveau de l'équipe n'ont pas à construire le code de l'entreprise entière, seulement les modules dont ils sont responsables et les modules dépendants. S'il y a deux modules complètement indépendants et dans des équipes différentes, ils ne feraient pas partie du cycle CI de l'autre équipe.
• Les cycles CI au niveau de l'équipe peuvent avoir des tests automatisés beaucoup plus détaillés que le cycle CI maître. Le cycle Master CI comporterait des tests de vérification d'intégrité et des tests de régression qui, selon la taille de la solution principale, seraient exécutés quotidiennement ou même chaque semaine, car ces tests peuvent parfois prendre plus de 24 heures à exécuter.

Ce que vous devez faire avec cette approche est de fournir une transmission automatisée des référentiels locaux au référentiel central une fois le cycle CI local passé, de peur que vos développeurs ne passent énormément de temps à pousser le code vers les référentiels centraux.

En plus de ce que @Vladimir_Stokic a dit, sur certaines équipes (la mienne a environ 150 développeurs), nous construisons plus fréquemment que toutes les 24 heures. Chaque fois qu'un commit se produit, nous démarrons un minuteur de 5 minutes. Une fois les 5 minutes écoulées, tous les commits survenus au cours de l'intervalle de 5 minutes sont combinés et générés. La génération est généralement une génération incrémentielle. Nous avons un générateur distinct qui exécute des tests unitaires pour chaque build qui se produit. Une fois la génération terminée, s'il y a eu d'autres validations pendant la génération (ce qui prend entre 1 et 45 minutes selon ce qui a changé), toutes les modifications en attente sont générées, etc. Nous avons également une version nocturne (propre, complète), mais les versions qui se produisent sur chaque commit (grossièrement) nous indiquent très rapidement si les tests échouent.