Lire en anglais

Partager via

Architecture de base de référence CI/CD avec Azure Pipelines

  • Article

Cet article décrit un flux de travail DevOps de haut niveau pour déployer des modifications d’application dans des environnements de préproduction et de production dans Azure. La solution utilise des pratiques d’intégration continue/de déploiement continu (CI/CD) avec Azure Pipelines.

Important

Cet article traite d’une architecture CI/CD générale à l’aide d’Azure Pipelines. Il n’est pas destiné à couvrir les spécificités du déploiement sur différents environnements, tels qu’Azure App Services, les machines virtuelles et Azure Power Platform. Les spécificités de la plateforme de déploiement sont abordées dans des articles distincts.

Architecture

diagramme d’architecture d’un pipeline CI/CD à l’aide d’Azure Pipelines.

Téléchargez un fichier Visio de cette architecture.

Notes

Bien que cet article traite de CI/CD pour les modifications d’application, Azure Pipelines peut également être utilisé pour générer des pipelines CI/CD pour les modifications d’infrastructure en tant que code (IaC).

Dataflow

Les données transitent par le scénario comme suit :

  1. Pipelines PR : une demande de tirage (PR, Pull Request) vers Azure Repos Git déclenche un pipeline PR. Ce pipeline exécute des vérifications de qualité rapides. Ces vérifications doivent inclure :

    • Création du code, qui nécessite l’extraction de dépendances à partir d’un système de gestion des dépendances.
    • Utilisation d’outils pour analyser le code, comme l’analyse statique du code, le linting et l’analyse de sécurité
    • Tests unitaires

    Si l’une des vérifications échoue, l’exécution du pipeline se termine et le développeur devra apporter les modifications requises. Si tous les contrôles réussissent, le pipeline doit nécessiter une révision de demande de tirage. Si la révision de PR échoue, la chaîne de production se termine et le développeur devra apporter les modifications requises. Si tous les contrôles et les révisions de tirage réussissent, la demande de tirage est fusionnée avec succès.

  2. Pipelines CI : une fusion vers Azure Repos Git déclenche un pipeline CI. Ce pipeline exécute les mêmes contrôles que le pipeline PR, avec quelques ajouts importants. Le pipeline CI exécute des tests d’intégration. Les tests d’intégration peuvent être gourmands en ressources, de sorte que leur exécution dans le pipeline CI équilibre la vitesse de développement et la détection des bogues. Il est également important de noter que le passage de tests dans une pull request ne garantit pas toujours leur réussite après la fusion, car les modifications de la branche principale peuvent introduire de nouveaux problèmes, soulignant ainsi la nécessité des tests post-fusion. Ces facteurs rendent le pipeline CI mieux adapté aux tests d'intégration que le pipeline PR. Ces tests d’intégration ne doivent pas nécessiter le déploiement de la solution, car les artefacts de build n’ont pas encore été créés. Si les tests d’intégration nécessitent des secrets, le pipeline obtient ces secrets à partir d’Azure Key Vault. Si l’une des vérifications échoue, le pipeline se termine et le développeur devra apporter les modifications requises. Le résultat d’une exécution réussie de ce pipeline est la création et la publication d’artefacts de build.

  3. Déclencheur de pipeline CD : la publication d’artefacts déclenche le pipeline CD.

  4. Publication CD vers un environnement intermédiaire : le pipeline CD télécharge les artefacts de build créés dans le pipeline CI et déploie la solution dans un environnement intermédiaire. Le pipeline exécute ensuite des tests d’acceptation sur l’environnement intermédiaire pour valider le déploiement. Si un test d’acceptation échoue, le pipeline se termine et le développeur devra apporter les modifications requises. Si les tests réussissent, une tâche de validation manuelle peut être implémentée pour exiger qu’une personne ou un groupe valide le déploiement et reprenne le pipeline.

  5. Publication CD vers l’environnement de production : si l’intervention manuelle est reprise, ou si aucune intervention manuelle n’est implémentée, le pipeline publie la solution en production. Le pipeline doit exécuter des tests de détection de fumée en production pour s’assurer que la mise en production fonctionne comme prévu. Si une étape d’intervention manuelle entraîne une annulation, si la mise en production échoue ou si les tests de fumée échouent, la mise en production est annulée, le pipeline se termine et le développeur doit apporter les modifications nécessaires.

  6. Monitoring : Azure Monitor collecte les données d’observabilité telles que les journaux et les métriques afin qu’un opérateur puisse analyser les données d’intégrité, de performance et d’utilisation. Application Insights collecte toutes les données de surveillance spécifiques à l’application, telles que les traces. Azure Log Analytics est utilisé pour stocker toutes ces données.

Composants

  • Un référentiel Gi Azure Repos sert de dépôt de code qui fournit la gestion de versions et une plateforme pour les projets collaboratifs.

  • azure Pipelines offre un moyen de générer, tester, empaqueter et publier du code d’application et d’infrastructure. Cet exemple comporte trois pipelines distincts avec les responsabilités suivantes :

    • Les pipelines de tirage valident le code avant d’autoriser une demande de tirage à fusionner par le biais du linting, de la génération et du test unitaire.
    • Les pipelines CI s’exécutent après la fusion du code. Ils effectuent la même validation que les pipelines PR, mais ajoutent des tests d’intégration et publient des artefacts de build si tout réussit.
    • Les pipelines CD déploient des artefacts de build, exécutent des tests d’acceptation et publient en production.

  • flux Azure Artifact vous permettent de gérer et de partager des packages logiciels, tels que Maven, npm et NuGet. Les flux d’artefacts vous permettent de gérer le cycle de vie de vos packages, notamment le contrôle de version, la promotion et la mise hors service des packages. Cela vous permet de vous assurer que votre équipe utilise les versions les plus récentes et les plus sécurisées de vos packages.

  • key Vault permet de gérer des données sécurisées pour votre solution, notamment les secrets, les clés de chiffrement et les certificats. Dans cette architecture, elle est utilisée pour stocker les secrets d’application. Ces secrets sont accessibles via le pipeline. Les secrets sont accessibles par Azure Pipelines avec une tâche Key Vault ou en liant des secrets à partir de Key Vault.

  • Monitor est une ressource d’observabilité qui collecte et stocke les métriques et les journaux, la télémétrie des applications et les métriques de plateforme pour les services Azure. Utilisez ces données pour surveiller l’application, configurer des alertes, des tableaux de bord et effectuer une analyse de la cause racine des défaillances.

  • Application Insights est un service de supervision qui fournit des insights en temps réel sur les performances et l’utilisation de vos applications web.

  • 'espace de travail Log Analytics fournit un emplacement central où vous pouvez stocker, interroger et analyser des données à partir de plusieurs sources, notamment des ressources, des applications et des services Azure.

Alternatives

Bien que cet article se concentre sur Azure Pipelines, vous pouvez envisager ces alternatives :

  • azure DevOps Server peut être utilisé comme substitut local.

  • Jenkins est un outil open source utilisé pour automatiser les builds et les déploiements.

  • GitHub Actions vous permettent d’automatiser vos flux de travail CI/CD directement à partir de GitHub.

  • Les référentiels GitHub peuvent être remplacés comme référentiel de code. Azure Pipelines s’intègre en toute transparence aux référentiels GitHub.

Cet article se concentre sur les pratiques générales de CI/CD avec Azure Pipelines. Voici quelques environnements de calcul sur lesquels vous pouvez envisager de déployer :

  • App Service est un service HTTP pour l’hébergement d’applications web, d’API REST et de back-ends mobiles. Vous pouvez développer dans votre langage favori, et les applications s’exécutent et s’adaptent facilement aux environnements Windows et Linux. Web Apps prend en charge les emplacements de déploiement tels que la préproduction et la production. Vous pouvez déployer une application sur un emplacement intermédiaire et la libérer sur l’emplacement de production.

  • Machines Virtuelles Azure gèrent les charges de travail qui nécessitent un degré élevé de contrôle ou dépendent de composants et services du système d'exploitation, ce qui n'est pas réalisable avec les Web Apps.

  • Azure Power Platform est un ensemble de services cloud qui permettent aux utilisateurs de créer, déployer et gérer des applications sans avoir besoin d’une infrastructure ou d’une expertise technique.

  • Azure Functions est une plateforme de calcul serverless que vous pouvez utiliser pour créer des applications. Avec Functions, vous pouvez utiliser des déclencheurs et des liaisons pour intégrer des services. Functions prend également en charge les emplacements de déploiement tels que la préproduction et la production. Vous pouvez déployer une application sur un emplacement intermédiaire et la libérer sur l’emplacement de production.

  • Azure Kubernetes Service (AKS) est un cluster Kubernetes managé dans Azure. Kubernetes est une plateforme d’orchestration de conteneurs open source.

  • Azure Container Apps vous permet d’exécuter des applications conteneurisées sur une plateforme serverless.

Détails du scénario

L’utilisation de pratiques CI et CD éprouvées pour déployer des modifications d’application ou d’infrastructure offre différents avantages, notamment :

  • cycles de publication plus courts - Les processus CI/CD automatisés vous permettent de déployer plus rapidement que les pratiques manuelles. De nombreuses organisations déploient plusieurs fois par jour.
  • Meilleure qualité du code : les exigences de qualité dans les pipelines CI, telles que le linting et les tests unitaires, entraînent un code de qualité supérieur.
  • Diminution du risque de publication : les pratiques CI/CD appropriées diminuent considérablement le risque de publier de nouvelles fonctionnalités. Le déploiement peut être testé avant la mise en production.
  • Augmentation de la productivité - Le CI/CD automatisé libère les développeurs du travail sur des intégrations et des déploiements manuels, leur permettant ainsi de se concentrer sur de nouvelles fonctionnalités.
  • Activer les restaurations : bien que les pratiques CI/CD appropriées réduisent le nombre de bogues ou de régressions qui sont libérés, ils se produisent toujours. CI/CD peut activer les restaurations automatisées vers des versions antérieures.

Cas d’usage potentiels

Tenez compte des processus AZURE Pipelines et CI/CD pour :

  • Accélération du développement d’applications et des cycles de vie de déploiement.
  • Création d’une qualité et d’une cohérence dans un processus de génération et de mise en production automatisé.
  • Augmentation de la stabilité et du temps d’activité de l’application.

Considérations

Ces considérations implémentent les piliers d’Azure Well-Architected Framework, qui est un ensemble d’ensembles guidants qui peuvent être utilisés pour améliorer la qualité d’une charge de travail. Pour plus d’informations, consultez Microsoft Azure Well-Architected Framework.

Excellence opérationnelle

  • Implémentez l’Infrastructure en tant que code (IaC) pour définir votre infrastructure et la déployer dans vos pipelines.

  • Envisagez d’utiliser l’une des tâches de segmentation du texte en unités lexicales disponibles sur la place de marché VSTS, qui dans le contexte, font souvent référence à un processus dans lequel des informations sensibles (telles que des clés API, des mots de passe ou autres secrets) sont remplacées par des jetons ou des espaces réservés pendant le déploiement ou la configuration.

  • Utilisez les variables de déploiement dans vos définitions de déploiement pour piloter les modifications de configuration de vos environnements. Les variables de mise en production peuvent être étendues à une version entière ou à un environnement donné. Lorsque vous utilisez des variables pour les informations secrètes, veillez à sélectionner l’icône de cadenas.

  • Envisagez d’utiliser des agents auto-hébergés si vous déployez sur des ressources s’exécutant dans un réseau virtuel sécurisé. Vous pouvez également envisager des agents auto-hébergés si vous exécutez un volume élevé de builds. Dans les cas de volumes de build élevés, les agents auto-hébergés peuvent être utilisés pour accélérer les builds de manière économique.

  • Envisagez d’utiliser application Insights et d’autres outils de supervision dès que possible dans votre pipeline de mise en production. De nombreuses organisations commencent uniquement à surveiller dans leur environnement de production. En surveillez vos autres environnements, vous pouvez identifier les bogues plus tôt dans le processus de développement et éviter les problèmes dans votre environnement de production.

  • Envisagez d’utiliser des ressources de surveillance distinctes pour la production.

  • Envisagez d’utiliser pipelines YAML au lieu de l’interface classique. Les pipelines YAML peuvent être traités comme d’autres codes. Les pipelines YAML peuvent être intégrés dans la gestion du code source et versionnés, par exemple.

  • Envisagez d’utiliser modèles YAML pour promouvoir la réutilisation et simplifier les pipelines. Par exemple, les pipelines PR et CI sont similaires. Un modèle paramétrable unique peut être utilisé pour les deux pipelines.

  • Envisagez de créer des environnements au-delà de la préproduction et de la production pour prendre en charge des activités telles que les tests d’acceptation manuelle des utilisateurs, les performances et les tests de charge, ainsi que les restaurations.

Optimisation des coûts

L’optimisation des coûts consiste à examiner les moyens de réduire les dépenses inutiles et d’améliorer l’efficacité opérationnelle. Pour plus d’informations, consultez Vue d’ensemble du pilier d’optimisation des coûts.

Les coûts d’Azure DevOps dépendent du nombre d’utilisateurs de votre organisation qui nécessitent un accès, ainsi que d’autres facteurs tels que le nombre de builds/versions simultanées requises et le nombre d’utilisateurs de test. Pour plus d’informations, consultez la page Tarification Azure DevOps.

Cette calculatrice de prix fournit une estimation de l’exécution d’Azure DevOps avec 20 utilisateurs.

Azure DevOps est facturé par utilisateur par mois. Des frais supplémentaires peuvent s’appliquer en fonction des pipelines simultanés requis, ainsi que de l’ajout d’utilisateurs de test et de licences de base utilisateur.

Sécurité

  • Tenez compte des avantages de sécurité de l’utilisation d’agents hébergés par Microsoft lorsque vous choisissez d’utiliser des agents hébergés par Microsoft ou auto-hébergés.

  • Vérifiez que toutes les modifications apportées aux environnements sont effectuées via des pipelines. Implémentez des contrôles d’accès en fonction du rôle (RBAC) sur le principe du privilège minimum, ce qui empêche les utilisateurs d’accéder aux environnements.

  • Envisagez d’intégrer des étapes dans Azure Pipelines pour suivre les dépendances, gérer les licences, rechercher des vulnérabilités et conserver les dépendances à jour.

Étapes suivantes

Passez en revue les ressources suivantes pour en savoir plus sur CI/CD et Azure DevOps :