architecture de référence CI/CD pour Azure Pipelines

Cet article présente une architecture de base pour la création d’un pipeline d’intégration continue et de déploiement continu (CI/CD) avec Azure Pipelines. Utilisez cette architecture comme point de départ si vous devez automatiser la création, le test et le déploiement d’applications dans des environnements de préproduction et de production dans Azure. L’architecture définit trois pipelines, demande de tirage (PULL), intégration continue (CI) et déploiement continu (CD) et montre comment ils fonctionnent avec Azure Repos, Azure Key Vault et Azure Monitor pour valider, générer et déployer vos applications en toute sécurité.

Architecture

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

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

Remarque

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 vérifications que le pipeline de PR, ainsi que les tests d’intégration. Le pipeline CI exécute des tests d’intégration au lieu du pipeline pr pour deux raisons :

    • Les tests d’intégration peuvent être gourmands en ressources ; les exécuter après une fusion de code permet donc de concilier la vitesse de développement et la détection des bogues.
    • Le fait que les tests réussissent dans une PR ne garantit pas qu’ils réussiront encore après la fusion, car les modifications apportées à la branche principale peuvent introduire de nouveaux problèmes que seuls les tests post-fusion peuvent détecter.

    Ces tests d’intégration ne doivent pas nécessiter le déploiement de la solution, car les artefacts de build ne sont pas encore créés. Si un test nécessite des secrets, le pipeline les récupère de Azure Key Vault. Si une vérification échoue, le pipeline se termine et le développeur doit apporter les modifications requises. Une exécution réussie de ce pipeline crée et publie les 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.

  • Azure Artifacts flux vous permettent de gérer et de partager des packages logiciels, tels que Maven, npm et NuGet. Les flux vous permettent de gérer le cycle de vie de vos packages, notamment la gestion des versions, la promotion et la mise hors service des packages, ce qui vous permet de garantir que votre équipe utilise les dernières versions et les plus sécurisées de vos dépendances.

  • 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. App Service prend en charge les emplacements de déploiement tels que la préproduction et la production. Vous pouvez donc déployer une application sur un emplacement intermédiaire et la libérer sur l’emplacement de production.

  • Machines virtuelles Azure gère les charges de travail qui nécessitent un degré élevé de contrôle ou dépendent des composants et services du système d'exploitation qui ne sont pas possibles avec App Service.

  • 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.
  • Réduction du risque de publication : les pratiques CI/CD appropriées réduisent considérablement le risque de publication de nouvelles fonctionnalités, car 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, un ensemble de principes directeurs que vous pouvez utiliser 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.

  • 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 effectuez un déploiement sur des ressources s’exécutant dans un réseau virtuel sécurisé, ou si vous exécutez un volume élevé de builds. Les agents auto-hébergés peuvent vous aider à accélérer les builds de manière économique à grande échelle.

  • 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 les vulnérabilités et maintenir les dépendances à jour.

Étapes suivantes

Créez votre premier pipelineGénérez, testez et déployez des projets .NET CoreGénérez et déployez une application web Node.js

  • Last updated on