Qu'est-ce qu'un serveur de CI ?

At the start of any CI/CD pipeline is an integration with your version or source control system.

L'implémentation de base consiste à configurer votre serveur de CI/CD pour surveiller les commits sur la branche master et déclencher le pipeline lorsqu'une modification est effectuée.

Bien que cela garantisse que chaque commit soit vérifié et testé, il reste une grande marge de manœuvre pour qu'une personne effectue un commit qui affecte le build, interrompant le processus et empêchant les autres modifications d'être vérifiées jusqu'à ce que le code concerné soit retiré ou corrigé.

Configurer votre serveur de CI pour qu'il crée et teste vos modifications avant qu'elles ne soient validées permet d'éviter ce type de problème et crée une boucle de feedback supplémentaire pour chaque développeur.

Il est important de noter que le serveur de build joue à la fois le rôle de facilitateur et d'exécuteur : il se charge d'exécuter le build et les tests sur un ordinateur distant et renvoie les résultats à l'utilisateur, mais il fait également de ce processus une condition pour décider d'effectuer un commit sur le master ou une branche de fonctionnalité.

Vous pouvez également envisager d'intégrer votre serveur de CI à votre outil de révision de code afin que chaque commit soit soumis à une révision de code avant d'être livré, passé avec succès une étape de build et de test.

Appliquer ces couches supplémentaires de logique métier au début du processus permet de garder votre base de code propre et prête à être publiée en production, tout en minimisant les interruptions et les retards dans le pipeline.

Lorsqu'il s'agit des phases de build et de test d'un pipeline CI/CD, votre serveur CI est le cerveau de l'opération, coordonnant les tâches et attribuant les travaux aux agents de build en fonction de divers critères.

Vos agents de build, cependant, se chargent des tâches les plus importantes, à savoir l'exécution des builds et des tests en fonction des instructions reçues du serveur CI.

Afin d'éviter les conflits de ressources et les problèmes de performance, il est recommandé de garder votre serveur de build distinct des agents de build sur lesquels vous exécutez les builds et les tests, au moins dans une configuration de production.

Lorsque vous utilisez votre serveur de CI pour configurer la logique d'une étape de votre pipeline, vous pouvez spécifier un ensemble de détails et de règles. Par exemple, vous pouvez vouloir exécuter certains tests sur les commits de la branche master, mais pas lors de l'exécution d'un build pre-commit sur une branche de développement, ou vous pouvez vouloir contrôler combien de builds peuvent appeler une base de données de test en même temps.

Exécuter certaines tâches en même temps, en utilisant différents agents de build, peut rendre votre pipeline plus efficace. Cette méthode est utile si vous avez besoin d'exécuter des tests sur différents systèmes d'exploitation ou si vous travaillez sur une énorme base de code dont les tests se comptent par centaines de milliers avec pour seule option pratique la mise en parallèle. In the latter case, setting up a composite build will aggregate the results so you can treat the tasks as a single build step.

Un serveur de build qui s'intègre à une infrastructure hébergée dans le cloud, comme AWS, vous permet de bénéficier de ressources flexibles et évolutives pour exécuter vos builds et vos tests. Si vos besoins en infrastructure sont considérables, la prise en charge des agents de build conteneurisés et l'intégration avec Kubernetes vous permettront de gérer efficacement vos ressources de build, qu'elles soient dans le cloud ou sur site.

Une partie essentielle de votre logique métier consiste à définir ce qui constitue un échec à chaque étape de votre pipeline de CI/CD.

Your CI server should allow you to configure various failure conditions, which it will then apply and use to determine the status of a particular step and whether to proceed to the next stage of the pipeline.

En plus des échecs évidents, tels que le retour d'un code d'erreur ou l'échec de l'exécution des tests, vous pouvez définir d'autres types d'échec basés sur les données collectées par votre serveur de build.

Par exemple, la couverture de test diminue par rapport au build précédent (ce qui indique que les tests n'ont pas été ajoutés pour les dernières modifications du code), ou le nombre de tests ignorés augmente par rapport au dernier build réussi.

Ces métriques constituent un avertissement pertinent quant à une éventuelle détérioration de la qualité du code. En déclenchant un échec pour ces raisons et en limitant les utilisateurs autorisés à passer outre ces échecs, vous pouvez favoriser un comportement optimal.

Bien que le nom « serveur de CI » suggère que leur utilisation se limite à l'intégration continue, la plupart des serveurs de CI prennent également en charge la livraison et le déploiement continus.

Après avoir produit vos artefacts de build et exécuté une première série de tests au cours de la phase d'intégration continue, l'étape suivante consiste à déployer ces artefacts dans des environnements d'assurance qualité pour d'autres niveaux de tests, puis à les mettre en préproduction pour que vos partenaires puissent les essayer, et enfin, si tout semble correct, à les publier en production.

As well as providing an artifact repository to store the outputs from each build so you can deploy them as needed, a CI/CD server can also store and manage parameters for each environment in your pipeline. Vous pouvez ensuite indiquer si vos scripts de déploiement sont déclenchés automatiquement en fonction du résultat de l'étape précédente.

Fournir un retour d'information rapide à chaque étape est un élément clé d'un pipeline de CI/CD.

Un serveur de build peut fournir des informations sur les tâches en attente, des rapports en temps réel sur les builds et les tests en cours, et le statut des étapes de build terminées.

En activant les notifications, vous pouvez vous assurer que vous et votre équipe êtes au courant de tous les problèmes dès qu'ils surviennent, tandis que l'intégration avec les outils de suivi des bugs vous permet de voir les détails des correctifs qui ont été inclus dans un commit et d'approfondir rapidement la cause d'un échec. Les données historiques peuvent fournir des informations utiles pour améliorer votre pipeline, ainsi que pour définir des conditions dans le cadre de la logique du pipeline.

Un serveur d'intégration continue joue un rôle essentiel dans l'implémentation de votre pipeline de CI/CD, en coordonnant et en déclenchant les différentes étapes de votre processus, et en collectant et en fournissant les données de chaque étape. Have a look at our Guide to CI/CD tools for tips on how to choose the right CI server for your organization.