Qu'est-ce que l'automatisation de build en DevOps ?
Les builds automatisés jouent un rôle central dans l'automatisation de l'intégration continue (CI) et constituent l'un des éléments clés d'un pipeline de CI/CD. Il s'agit de la première d'une série d'étapes automatisées conçues pour vous alerter le plus tôt possible lorsque vos dernières modifications de code causent des problèmes.
Dans ce contexte, le terme « build » ne se limite pas à la compilation et la liaison du code source pour créer un exécutable.
Le processus de build automatisé comprend une série de vérifications ainsi que la collecte de tous les éléments nécessaires à l'exécution de votre programme ; même si vous travaillez dans un langage interprété, vous aurez besoin d'une étape de build.
Les fichiers issus de l'étape de build (connus sous le nom d'artefacts de build) sont ensuite acheminés dans votre pipeline de CI/CD pour d'autres étapes de test, puis de la préproduction. Si un build réussit toutes les étapes du pipeline, il est alors prêt à être publié en production.
Pourquoi automatiser le processus de build et de déploiement ?
Avant d'aborder l'automatisation des builds, examinons pourquoi un processus de gestion de build automatisé est important.
Si vous travaillez dans un IDE, vous pouvez déclencher un build avec un raccourci clavier, alors pourquoi automatiser le processus ?
Tout d'abord, bien que les builds locaux sont pratiques lorsque vous voulez vérifier votre travail ou faire une démonstration rapide à votre responsable, leur utilisation pour votre pipeline de CI/CD n'est pas une bonne pratique.
L'utilisation d'un serveur de build dédié garantit un environnement propre et la détection rapide de toute dépendance manquante qui, autrement, causerait des problèmes et des retards lors du déploiement du résultat dans un environnement de test.
Sans une étape de build automatisée préalable aux autres étapes du pipeline, le CI/CD serait beaucoup moins fiable. Si vous devez vous souvenir de vous connecter au serveur de build et d'exécuter chaque build, y compris tous les tests, de superviser le processus pour détecter les erreurs éventuelles et de déplacer les artefacts de sortie dans le référentiel d'artefacts<0> afin qu'ils puissent être déployés pour les tests, votre processus est alors sujet aux erreurs.
Il peut être tentant de reporter la création du build jusqu'à ce que vous ayez des modifications supplémentaires à tester, mais vous compromettez les avantages du CI/CD en agissant ainsi.
De plus, la stratégie derrière un pipeline de CI/CD consiste à détecter les erreurs le plus tôt possible.
Plus tôt vous découvrez un problème, plus il est facile de le résoudre et plus votre processus d'automatisation de build gagne en efficacité. L'automatisation de la phase de build est plus rapide que le déclenchement manuel des différentes étapes concernées, et beaucoup plus efficace que de déplacer des fichiers et d'exécuter des tests à la main.
En automatisant le build, vous vous assurez que toutes les étapes sont exécutées dans le bon ordre sur chaque commit (ou sur un lot de commits) et bénéficiez d'un retour d'information rapide tout en gagnant du temps.
Comment fonctionne l'automatisation de build dans votre pipeline CI/CD ?
Si vous êtes débutant en CI/CD, la configuration de builds automatisés et leur déclenchement chaque fois qu'un membre de votre équipe effectue une modification est l'une des premières mesures à prendre (après avoir tout mis dans le contrôle de code source). Vous disposez peut-être déjà d'un script de build ou d'un fichier de définition, fourni par votre IDE ou écrit par vos soins.
Si ce n'est pas le cas, vous devez choisir un outil d'automatisation de build adapté au langage dans lequel vous travaillez et spécifier les fichiers à compiler, lier et empaqueter. Vous pouvez ensuite utiliser un serveur de CI pour coordonner les différentes étapes, du déclenchement initial au retour d'information, en passant par la définition des conditions d'échec.
Déclenchement d'un build
L'intégration continue automatisée consiste à déclencher un build après chaque commit dans la branche principale, afin d'intégrer et de tester chaque modification peu de temps après l'avoir effectuée. Si le build se déroule correctement, il déclenche alors l'étape suivante du processus.
La plupart des outils de CI vous permettent de configurer des déclencheurs supplémentaires pour le build et de personnaliser les étapes du pipeline qui suivent.
Par exemple, vous pouvez déclencher les mêmes étapes lorsque des commits sont effectués dans les branches d'un dossier particulier. D'autre part, à l'aide d'un outil de déploiement, vous pouvez programmer un process de build qui se déroule la nuit et est soumis à des couches de test supplémentaires, puis est utilisé pour actualiser les environnements de préproduction. Vous pouvez également lancer l'étape de build manuellement.
Exécution d'un build
Une bonne pratique consiste à exécuter les étapes de build sur un serveur de build dédié plutôt que sur votre ordinateur de développement. Effectuer le build dans un nouvel environnement permet de signaler les dépendances manquantes et d'éviter les problèmes du type « ça fonctionne sur ma machine ».
L'étape de build proprement dite fait appel à l'outil d'automatisation de build que vous avez choisi (comme Maven, Ant ou Gradle), qui exécute les tâches spécifiées dans le script de build ou le fichier de définition.
Une fois que vous avez une idée de la durée d'exécution de vos builds, il est intéressant d'utiliser un outil de déploiement pour configurer une condition d'échec pour les builds qui ne se terminent pas dans une période donnée. Cette pratique permet d'éviter que des builds interminables ne bloquent les ressources.
Exécution des tests
En plus de préparer votre code pour le déploiement, le processus de gestion de build automatisé est un point de départ idéal pour exécuter un certain nombre d'autres vérifications du code, comme les tests unitaires, le linting et l'analyse statique du code. L'exécution de ces vérifications dans le cadre de chaque build avec des outils de déploiement et la résolution des problèmes dès qu'ils surviennent vous aident à améliorer la qualité de votre code.
Bien que ces vérifications soient effectuées avant la production des artefacts de build, un échec ne doit pas nécessairement arrêter le reste du pipeline. Par exemple, vous pouvez décider de publier l'artefact de build et de passer à l'étape suivante du pipeline même si des erreurs de linting ont été trouvées. La configuration d'un seuil de qualité permet d'éviter que les « petits » problèmes ne s'accumulent au fil du temps.
Publication des artefacts de build
Le produit final d'un processus de build automatisé est constitué d'artefacts de build, qui peuvent inclure des programmes d'installation, des fichiers WAR, des bibliothèques et des conteneurs. La publication de ces fichiers dans un référentiel d'artefacts vous fournit un emplacement central à partir duquel vous pouvez déployer des builds dans différents environnements, dans l'idéal au moyen d'outils de déploiement.
Après le build, l'étape suivante d'un pipeline de CI/CD implique généralement des tests fonctionnels automatisés, qui nécessitent le déploiement du build dans un ou plusieurs environnements de test (parfois avec d'autres composants, tels qu'une base de données ou d'autres microservices). Si ces tests sont concluants, le même build peut être utilisé pour actualiser les environnements de test et, éventuellement, être publié en production.
Métriques et retour d'information
Vous pouvez consulter les résultats de la phase de build, notamment si le build a été créé correctement et les résultats des tests unitaires et autres vérifications, à partir de votre outil de CI. Configurer des alertes pour vous signaler les défaillances vous permet de réagir rapidement et de maintenir votre code dans un état constamment publiable.
Un outil de déploiement rassemble également les données de votre pipeline pour vous permettre d'analyser les tendances. En examinant l'historique des builds et des indicateurs tels que la durée des builds, les taux de réussite et la couverture du code, vous obtenez des informations qui vous aideront à améliorer votre processus de CI/CD.
Conclusion
L'automatisation de vos builds est l'une des premières étapes essentielles de la configuration d'un pipeline de CI/CD et la gestion globale du build. Par conséquent, l'adoption d'outils de déploiement appropriés est une bonne pratique. La phase de build fournit la première série de retours d'information rapides et active les étapes suivantes du pipeline, depuis les tests automatisés jusqu'à la livraison et le déploiement continus.