Automatisation des tests et pipeline de livraison

Vous avez découvert le déploiement et la livraison continus de logiciels et de services, mais ces deux aspects font en fait partie d’un trio. Les pratiques DevOps visent à réaliser une intégration, une livraison et un déploiement continus. Ces pratiques sont généralement créées dans cet ordre, chacune d’elles dépend de celle qui l’a précédée.

Revenons au premier aspect : l’intégration. Elle fait partie du processus de développement qui précède le déploiement. DevOps recommande une pratique de développement dans laquelle les membres de l’équipe intègrent fréquemment du code dans un dépôt partagé contenant un code base « principal » singulier. L'objectif est de demander à tout le monde de contribuer au code qui sera livré, plutôt que de travailler sur leur propre copie et de tout rassembler uniquement à la dernière minute.

Les tests automatisés peuvent ensuite vérifier l’intégration de chaque membre de l’équipe. Ces tests permettent de déterminer si le code est « sain », une fois que tous les changements et ajouts ont été effectués. Le test fait partie de ce qui est communément appelé pipeline. Le reste de cette unité se concentre sur les pipelines de test et de livraison intégrés.

Pipeline de livraison continue

Pour comprendre le rôle des tests automatisés dans le modèle de déploiement de livraison continue, vous devez voir où il s’intègre dans le pipeline de livraison. Un pipeline de livraison continue est l’implémentation de l’ensemble des étapes du code au fur et à mesure que des changements sont apportés durant le processus de développement et avant le déploiement en production. Voici une représentation graphique d’exemples d’étapes dans un pipeline de livraison simplifié :

Parcourez ce pipeline étape par étape :

• Une instance du pipeline démarre au fur et à mesure que les changements apportés au code ou à l’infrastructure sont commités dans un dépôt de code, éventuellement à l’aide d’une demande de tirage (pull request).

• Ensuite, les tests unitaires s’exécutent, souvent suivis de tests d’intégration ou de bout en bout. Les résultats sont transmis au développeur qui a ouvert la pull request.

• À ce stade, le code du référentiel est souvent analysé pour les secrets, les vulnérabilités et les configurations incorrectes.

• Une fois que tout est vérifié, le code est généré et préparé au déploiement.

• Le code est ensuite déployé sur un environnement de test. Un réviseur peut être averti du nouveau déploiement afin qu’il puisse examiner la solution de préproduction. Le réviseur approuve ou refuse ensuite la promotion en production, ce qui démarre la dernière partie du processus de déploiement qui libère le code en production.

Dans ce pipeline, vous pouvez remarquer la délimitation entre l’intégration et le déploiement. Les marqueurs mis en surbrillance indiquent certains endroits logiques où vous pouvez arrêter le pipeline via une logique et une automatisation incluses, ou potentiellement même une intervention humaine.

Outils pour l’intégration et la livraison continues : Azure Pipelines et GitHub Actions

Pour utiliser l’intégration continue et la livraison continue, vous avez besoin des outils appropriés. Microsoft offre deux options CI/CD internes pour la création et le déploiement sur Azure : Azure Pipelines (partie de Azure DevOps) et GitHub Actions. Les deux peuvent automatiser la création et le test cohérent de votre code, et les deux peuvent être déployés sur des services Azure, des machines virtuelles et d’autres cibles dans le cloud et localement. De nombreuses équipes adoptent GitHub Actions lorsque leur code source vit déjà dans GitHub, tandis que Azure Pipelines reste un choix fort pour les équipes normalisées sur Azure DevOps.

Le reste de cette unité se concentre sur Azure Pipelines, mais GitHub Actions utilise des idées de haut niveau similaires même si la terminologie diffère. Dans GitHub Actions, les flux de travail contiennent des travaux et des étapes, des actions empaquetent l’automatisation réutilisable, les exécuteurs exécutent le travail et les environnements peuvent protéger les déploiements.

L’entrée d’un pipeline (votre code ou configurations) réside dans un système de contrôle de version tel que GitHub ou un autre fournisseur Git.

Azure Pipelines s’exécute sur le calcul, comme une machine virtuelle ou un conteneur, et offre des agents de build hébergés Microsoft exécutant Windows, Linux et macOS. Vous pouvez également inscrire vos propres agents auto-gérés lorsque vous avez besoin d’un contrôle total sur l’environnement de build. Il offre également une intégration avec les plug-ins de test, de sécurité et de qualité du code. Enfin, il est facilement extensible, de sorte que vous pouvez apporter votre propre automatisation dans Azure Pipelines.

Les pipelines sont définis à l’aide de la syntaxe YAML stockée en même temps que votre code dans un dépôt Git. Les pipelines YAML sont l’approche recommandée pour les nouveaux projets. Une interface utilisateur classique dans Azure DevOps est également disponible pour les pipelines hérités, mais la plupart des nouvelles fonctionnalités (y compris les travaux de conteneur et de nombreuses fonctionnalités avancées) sont uniquement YAML. Les pipelines fournissent également des modèles que vous pouvez utiliser pour créer facilement des pipelines, tels qu’un modèle pour une image Docker ou un projet Node.js. Vous pouvez également réutiliser un fichier YAML existant.

Les étapes de base de la configuration d’un pipeline sont les suivantes :

1. Configurez Azure Pipelines pour utiliser votre référentiel Git.
2. Définissez votre build en modifiant le fichier azure-pipelines.yml (ou, pour les pipelines hérités, à l’aide de l’éditeur Classic).
3. Poussez (push) votre code vers votre dépôt de gestion de versions. Cette action déclenche le pipeline de build et de test de votre code.

Une fois le code mis à jour, généré et testé, vous pouvez le déployer sur la cible de votre choix.

construction de pipeline Azure

Les pipelines sont structurés en :

• Travaux : un travail est un regroupement de tâches ou d’étapes qui s’exécute sur un seul agent de build. Un travail est la plus petite partie d’une activité dont vous pouvez planifier l’exécution. Toutes les étapes d’un travail s’exécutent de manière séquentielle. Ces étapes peuvent être n’importe quelle action dont vous avez besoin, notamment la génération ou la compilation de logiciels, la préparation d’exemples de données pour les tests, l’exécution de tests spécifiques, et ainsi de suite.

• Phases : une phase est un regroupement logique de travaux associés.

Chaque pipeline a au moins une phase. Utilisez plusieurs phases pour organiser le pipeline en divisions principales, puis marquez les points de votre pipeline où vous pouvez effectuer des interruptions et des vérifications.

Les pipelines peuvent être aussi simples ou complexes que vous le souhaitez. Pour des didacticiels sur la construction et l'utilisation de pipelines, consultez le parcours d’apprentissage Build applications with Azure DevOps.

Traçabilité de l’environnement

Il existe un autre aspect des pipelines lié à la fiabilité, et qui mérite d’être mentionné. Vous pouvez construire vos pipelines de façon à permettre la corrélation des éléments exécutés en production avec une instance de build spécifique. Dans l’idéal, vous devez pouvoir retracer une compilation vers une "pull request" ou une modification de code spécifique. Cette traçabilité est inestimable lors d’un incident, puis lors de la révision post-incident lorsque vous essayez d’identifier quelle modification a contribué à un problème. Certains systèmes CI/CD (comme Azure Pipelines et GitHub Actions) rendent cette corrélation simple, tandis que d’autres nécessitent que vous construisiez manuellement un pipeline qui propage un ID de build à chaque étape.