Git CI/CD : cinq conseils sur les dépôts Git permettant l'intégration continue

Un système de stockage comme Artifactory (qui a une extension pour Bamboo), Nexus ou Archiva peut s'avérer utile pour les artefacts générés par votre équipe ou les équipes qui vous entourent. Vous pouvez faire un pull des fichiers dont vous avez besoin dans le répertoire de build au début de votre build, comme les bibliothèques tierces dont vous faites un pull via Maven ou Gradle.

Si vous ne disposez pas encore d'un système de stockage externe sur votre réseau, il est plus facile de tirer parti de Git Large File Storage (LFS).

Git LFS est une extension qui stocke des pointeurs vers des fichiers volumineux à l'intérieur de votre dépôt, au lieu de stocker les fichiers réels. Les fichiers réels sont stockés sur un serveur distant.Comme vous pouvez l'imaginer, cela réduit considérablement le temps de clonage.

Il y a de fortes chances que vous ayez déjà accès à Git LFS, car Bitbucket et GitHub le prennent en charge.

Supposons que votre build nécessite l'ensemble de l'historique du dépôt, ce qui peut être le cas lorsque l'une des étapes de votre build met à jour le numéro de version dans votre POM (ou un autre élément similaire), ou lorsque vous mergez deux branches avec chaque build. Dans les deux cas, Bamboo doit faire un push des changements vers votre dépôt.

Grâce à Git, les changements simples apportés aux fichiers (comme mettre à jour un numéro de version) peuvent être pushés sans l'historique complet. L'historique du dépôt est toutefois nécessaire pour les merges, car Git doit revenir en arrière et trouver l'ancêtre commun des deux branches. Ceci peut poser problème si votre build utilise le clonage superficiel. Ceci m'amène au conseil nº 3.

Cette astuce accélère considérablement l'opération de clonage, et Bamboo l'applique par défaut.

Notez que la mise en cache du dépôt n'est bénéfique que si vous utilisez des agents qui perdurent build après build. Si vous créez et que vous détruisez les agents de build sur EC2 ou un autre fournisseur de cloud à chaque exécution de build, la mise en cache du dépôt n'aura pas d'importance, car vous travaillerez avec un répertoire de build vide et vous devrez quand même faire un pull d'une copie complète du dépôt à chaque fois.

Il peut être intéressant de combiner la mise en cache du dépôt et les clones superficiels (classés par agents persistants et flexibles). Voici une petite matrice pour vous aider à procéder de façon stratégique.

Il va sans dire, ou presque, que l'exécution de la CI sur toutes vos branches actives est une bonne idée. Mais est-il judicieux d'exécuter tous les builds sur toutes les branches avec tous les commits ? Probablement pas. Voici pourquoi.

Prenons Atlassian par exemple. Nous avons plus de 800 développeurs, et chacun d'entre eux pushe des changements dans le dépôt plusieurs fois par jour, la plupart du temps vers les branches de fonctionnalité. Ça fait beaucoup de builds. À moins de mettre à l'échelle vos agents de build instantanément et en continu, la file d'attente finit par être longue.

L'un de nos serveurs Bamboo internes héberge 935 plans de build différents. Nous avons connecté 141 agents de build dans ce serveur et nous avons appliqué les bonnes pratiques, comme la transmission des artefacts et la parallélisation des tests, pour rendre chaque build le plus performant. Pourtant, la génération après chaque push provoquait un blocage.

Au lieu de simplement configurer une autre instance Bamboo avec plus de 100 agents supplémentaires, nous avons pris du recul et nous nous sommes demandé si c'était réellement nécessaire. La réponse est : non.

Nous avons donc offert aux développeurs la possibilité de déclencher manuellement les builds sur les branches au lieu de toujours les déclencher automatiquement. C'est un bon moyen de parvenir à un équilibre entre des tests rigoureux et la préservation des ressources. De plus, la plupart des changements sont effectués au niveau des branches ; c'est donc une bonne occasion de faire des économies.

De nombreux développeurs apprécient le contrôle supplémentaire que leur procurent les builds déclenchés manuellement et sont d'avis qu'ils s'intègrent naturellement à leur workflow. D'autres préfèrent ne pas avoir à penser à l'exécution d'un build et restent sur des déclencheurs automatisés. Les deux approches sont valables. L'important est de tester vos branches en premier lieu et de vous assurer d'avoir un build propre avant de faire un merge en amont.

Néanmoins, il en va autrement des branches stratégiques, comme les branches principales et les branches release stables. Ici, les builds sont déclenchés automatiquement, soit en interrogeant le dépôt sur d'éventuels changements, soit en envoyant une notification Push de Bitbucket à Bamboo. Comme nous utilisons des branches develop pour tous nos projets en cours, les seuls commits transmis à la branche principale correspondent (en théorie) au merge de branches develop. D'autre part, voici les lignes de code à partir desquelles nous réalisons la livraison et nos branches develop. Il est donc très important que nous obtenions les résultats des tests en temps opportun par rapport à chaque merge.

Interroger votre dépôt toutes les X minutes à la recherche de changements est une opération assez peu onéreuse pour Bamboo. Mais lorsque vous mettez à l'échelle des centaines de builds par rapport à des milliers de branches impliquant des dizaines de dépôts, tout cela s'additionne rapidement. Au lieu de surcharger Bamboo avec toutes ces interrogations, vous pouvez demander à Bitbucket de prévenir lorsqu'un changement a été pushé et doit être généré.

En règle générale, il vous suffit d'ajouter un hook à votre dépôt. Mais en l'occurrence, l'intégration entre Bitbucket et Bamboo gère toute la configuration pour vous. Une fois qu'ils sont connectés sur le back-end, un build basé sur le dépôt déclenche Just Work™ dès l'installation. Pas de hooks ni de configurations spéciales nécessaires.

Quels que soient les outils, les déclencheurs gérés par le dépôt ont un avantage : ils disparaissent automatiquement lorsque la branche cible est inactive. En d'autres termes, vous ne perdrez pas votre temps à interroger des centaines de branches abandonnées lors des cycles de CPU de votre système de CI. Ni même à désactiver manuellement vos builds de branche. Notez cependant que Bamboo peut facilement être configuré de sorte à ignorer les branches après X jours d'inactivité si vous préférez interroger les branches manuellement.