Close

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

Garantissez votre succès : tout commence par votre dépôt.

Portrait de Sarah Goff-Dupont
Sarah Goff-Dupont

Principal Writer


Git et la livraison continue, c'est le délicieux mariage de deux saveurs complémentaires, un peu comme le chocolat et le beurre de cacahuète. C'est une combinaison merveilleuse, comme on en rencontre parfois dans l'univers des logiciels. Je souhaiterais donc vous donner quelques conseils afin de permettre à vos builds Bamboo d'interagir correctement avec vos dépôts Bitbucket. La plupart de leurs interactions interviennent dans les phases de développement et de test de la livraison continue ; j'aborderai donc principalement la question en termes d'intégration continue plutôt que de livraison continue.

1 : Stocker des fichiers volumineux en dehors de votre dépôt


Vous entendrez souvent ce commentaire à propos de Git : « Évitez de placer des fichiers volumineux (fichiers binaires, fichiers multimédias, artefacts archivés, etc.) dans votre dépôt ». En effet, lorsque vous ajoutez un fichier, il reste dans l'historique du dépôt, ce qui signifie que chaque fois que le dépôt est cloné, cet énorme fichier l'est lui aussi.

Extraire un fichier de l'historique du dépôt est délicat. Cela revient à pratiquer une lobotomie frontale sur votre base de code. Cette extraction chirurgicale d'un fichier affecte également l'historique complet du dépôt. Vous ne pouvez donc plus clairement distinguer quels changements ont été apportés et à quel moment. Ce sont effectivement de bonnes raisons d'éviter les fichiers volumineux en règle générale. Et…

Dans le cadre de l'intégration continue, il est particulièrement important de garder les fichiers volumineux hors de vos dépôts Git

À chaque génération, votre serveur CI doit cloner votre dépôt dans le répertoire du build de travail. Si votre dépôt est alourdi par des artefacts volumineux, le process est ralenti et les développeurs doivent attendre plus longtemps les résultats du build.

OK, parfait. Mais qu'en est-il si votre build dépend de fichiers binaires d'autres projets ou d'artefacts volumineux ? C'est une problématique très fréquente, qui reviendra probablement toujours. La question est donc : comment gérer cela efficacement ?

Découvrir la solution

Développez et exploitez des logiciels grâce à Open DevOps

Matériel connexe

En savoir plus sur le développement basé sur le tronc

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.

Conseil de pro : si les artefacts changent fréquemment, résistez à la tentation de synchroniser vos fichiers volumineux sur le serveur de build chaque nuit afin de ne devoir les transférer sur le disque qu'au moment du build. Entre chaque synchronisation nocturne, vous allez en effet créer des versions obsolètes des artefacts. Et, les développeurs ont besoin de ces fichiers pour réaliser des builds sur leurs postes de travail locaux. Pour résumer, la meilleure chose à faire reste d'intégrer le téléchargement d'artefacts au build.

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.

Git LFS

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

2 : Utiliser des clones superficiels pour la CI


Quand un build est exécuté, votre serveur clone votre dépôt dans le répertoire de travail actuel. Comme je l'ai indiqué précédemment, lorsque Git clone un dépôt, il clone tout l'historique du dépôt par défaut. Au fil du temps, cette opération sera donc de plus en plus longue.

Avec des clones superficiels, seul l'instantané actuel de votre dépôt peut faire l'objet d'un pull. Ils peuvent donc être très utiles pour accélérer les builds, notamment lorsque vous travaillez avec des dépôts volumineux et/ou plus anciens.

Capture d'écran de dépôts Git

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.

3 : Mettre en cache le dépôt sur les agents de build


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.

Capture d'écran des agents permanents et extensibles

4 : Choisissez vos déclencheurs judicieusement


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.

Vignette des déclencheurs continus

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.

5 : Privilégier le hooking au polling


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.

Capture d'écran de la configuration de Bitbucket

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.

Utiliser Git avec CI ? Rien de plus simple !


Il vous suffit de réfléchir. Tout ce qui fonctionnait très bien lorsque vous utilisiez la CI avec un VCS centralisé… fonctionnera peut-être moins bien avec Git. La première étape ? Vérifiez vos hypothèses. La deuxième ? Intégrez Bamboo à Bitbucket (si vous êtes un client Atlassian). Consultez notre documentation pour en savoir plus, et c'est parti !

Sarah Goff-Dupont
Sarah Goff-Dupont

Ingénieure QA de formation, Sarah Goff-Dupont est devenue rédactrice. Son travail a été présenté dans des revues comme Harvard Business Review, Inc., Huffington Post, ainsi que dans des publications spécialisées. Elle travaille à distance depuis son domicile dans le Minnesota et apprécie chaque minute de ses journées. Pendant son temps libre, elle lit, fait du snowboard, cuisine ou échange des jeux de mots vaseux avec ses enfants.

Se connecter avec Sarah sur LinkedIn


Partager cet article

Lectures recommandées

Ajoutez ces ressources à vos favoris pour en savoir plus sur les types d'équipes DevOps, ou pour les mises à jour continues de DevOps chez Atlassian.

Illustration DevOps

Communauté DevOps

Illustration DevOps

Lire le blog

Illustration d'une carte

Essayez la solution gratuitement

Inscrivez-vous à notre newsletter DevOps

Thank you for signing up