Architecture de base CI/CD avec Azure Pipelines

  • Article

Cet article décrit un workflow DevOps général pour le déploiement de modifications d’application dans des environnements intermédiaires 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 utilisant Azure Pipelines. Il n’a pas pour but de couvrir les spécificités du déploiement dans différents environnements, tels qu’Azure App Services, Machines Virtuelles et Azure Power Platform. Les spécificités de la plateforme de déploiement sont traitées dans des articles distincts.

Architecture

Diagramme d’architecture d’un pipeline CI/CD utilisant 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 circulent dans 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 contrôles de qualité rapides. Ces contrôles doivent comprendre ce qui suit :

    • Génération du code, qui nécessite le tirage des dépendances à partir d’un système de gestion des dépendances.
    • Utilisation d’outils pour analyser le code, tels que l’analyse statique du code, le linting et l’analyse de la sécurité.
    • Tests unitaires

    Si l’un des contrôles échoue, l’exécution du pipeline se termine et le développeur doit 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 demande de tirage échoue, le pipeline se termine et le développeur doit 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 les tests d’intégration. 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’un des contrôles échoue, le pipeline se termine et le développeur doit 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 doit apporter les modifications requises. Si les tests réussissent, une tâche de validation manuelle peut être implémentée afin d’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 monitoring propres à 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.

  • Les flux d’artefacts Azure 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, y compris le versioning, 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 offre un moyen de gérer les 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 superviser l'application, définir des alertes, configurer des tableaux de bord et effectuer une analyse de la cause racine des échecs.

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

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

Autres solutions

Bien que cet article soit axé sur Azure Pipelines, vous pouvez envisager ces alternatives :

  • Azure DevOps Server (autrefois appelé Team Foundation Server) peut faire office de 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 est axé sur les pratiques CI/CD générales avec Azure Pipelines. Voici quelques environnements de calcul dans lesquels vous pouvez envisager de déployer :

  • App Services 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 se mettent à l’échelle facilement dans les 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 de préproduction et la publier sur l’emplacement de production.

  • Les Machines virtuelles Azure permettent de gérer les charges de travail qui exigent un degré de contrôle élevé ou qui dépendent de services et de composants du système d’exploitation non utilisables avec Web Apps (par exemple, GAC Windows ou COM).

  • Azure Power Platform est une collection 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 les 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 de préproduction et la publier 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 éprouvées CI et CD pour déployer des modifications d’application ou d’infrastructure offre différents avantages, notamment :

  • Cycles de mise en production plus courts : les processus CI/CD automatisés vous permettent de déployer plus rapidement que les pratiques manuelles. De nombreuses organisations effectuent des déploiements 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.
  • Productivité accrue : l’intégration continue/la livraison continue permet aux développeurs de travailler sur des intégrations et des déploiements manuels afin qu’ils puissent 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 publiées, ceux-ci se produisent quand même. L’intégration continue et livraison continue peut activer les restaurations automatisées à des versions antérieures.

Cas d’usage potentiels

Les processus Azure Pipelines et CI/CD peuvent être envisagés pour ce qui suit :

  • Accélération du développement d’applications et des cycles de vie de développement
  • Qualité et cohérence de la construction dans un processus de compilation et de mise en production automatisé.
  • Amélioration de la stabilité et du temps d’activité des applications

Considérations

Ces considérations implémentent les piliers d’Azure Well-Architected Framework qui est un ensemble de principes directeurs qui permettent d’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 tokenisation disponibles sur la Place de marché VSTS, dans le contexte, faites souvent référence à un processus où les informations sensibles (telles que les clés d’API, les mots de passe ou d’autres secrets) sont remplacées par des jetons ou des espaces réservés pendant le déploiement ou la configuration.

  • Utilisez des variables de mise en production dans vos définitions de mise en production pour piloter les modifications de configuration de vos environnements. Les variables de mise en production peuvent être étendues à toute une version ou à un environnement donné. Si vous utilisez des variables pour les informations de secret, veillez à sélectionner l’icône en forme 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. En 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 des outils de supervision supplémentaires dès que possible dans votre pipeline de mise en production. De nombreuses organisations attendent d’être dans leur environnement de production pour commencer la supervision. La supervision de vos autres environnements vous permet d’identifier les éventuels bogues plus tôt dans le processus de développement et d’éviter ainsi l’apparition de problèmes dans votre environnement de production.

  • Utilisez des ressources de monitoring distinctes pour la production.

  • Envisagez d’utiliser des pipelines YAML au lieu de l’interface Classique. Les pipelines YAML peuvent être traités comme d’autres codes. Les pipelines YAML peuvent être archivés dans le contrôle de code source et mis en version, par exemple.

  • Envisagez d’utiliser des 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.

  • Créez 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 tests de performances et de charge, et 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 varient selon le nombre d’utilisateurs de votre organisation qui nécessitent un accès, ainsi qu’en fonction d’autres facteurs tels que le nombre de builds/mises en production simultanés requis et le nombre d’utilisateurs de test. Pour plus d’informations, consultez la page Tarification Azure DevOps.

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

Azure DevOps est facturé par mois et par utilisateur. 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 en matière de sécurité offerts par l’utilisation d’agents hébergés par Microsoft lorsque vous choisissez entre l’utilisation d’agents hébergés par Microsoft ou d’agents auto-hébergés.

  • Vérifiez que toutes les modifications apportées aux environnements sont effectuées par le biais de pipelines. Implémentez des contrôles d’accès en fonction du rôle (RBAC) basés sur le principe des privilèges minimum, empêchant les utilisateurs d’accéder aux environnements.

  • Intégrez 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

Pour plus d’informations sur les déploiements CI/CD et Azure DevOps, consultez les ressources suivantes :