Share via

Configurer un pipeline et envoyer (push) des mises à jour

  • Article

Dans cet article, vous allez apprendre à utiliser Azure Developer CLI (azd) pour envoyer (push) des modifications de modèle via un pipeline CI/CD tel que GitHub Actions ou Azure DevOps. Pour cet exemple, vous allez utiliser l’application web React avec Node.js API et MongoDB sur le modèle Azure , mais vous pouvez appliquer les principes que vous découvrez dans cet article à l’un des modèles AZURE Developer CLI.

Remarque

La azd pipeline config commande est toujours en version bêta. En savoir plus sur la prise en charge des fonctionnalités alpha et bêta sur la page gestion des versions et stratégies de mise en production des fonctionnalités.

Prérequis

azd les modèles peuvent inclure ou non un fichier de configuration de pipeline GitHub Actions et/ou Azure DevOps appelé azure-dev.yml, qui est requis pour configurer CI/CD. Ce fichier de configuration provisionne vos ressources Azure et déploie votre code dans la branche principale. Vous trouverez azure-dev.yml:

  • Pour GitHub Actions : dans le .github/workflow répertoire.
  • Pour Azure DevOps : dans le .azdo/pipelines répertoire.

Vous pouvez utiliser le fichier de configuration tel qu’il est ou le modifier en fonction de vos besoins.

Remarque

Vérifiez que votre modèle a une définition de pipeline (azure-dev.yaml) avant d’appeler azd pipeline config. azd ne crée pas automatiquement ce fichier. Consultez Créer une définition de pipeline pour azd ci-dessous.

Pour configurer un pipeline CI/CD, vous allez utiliser la azd pipeline config commande, qui gère les tâches suivantes :

  • Crée et configure un principal de service pour l’application sur l’abonnement Azure. Votre utilisateur doit avoir un Owner rôle ou Contributor + User Access Administrator des rôles dans l’abonnement Azure, car pour permettre à azd de créer et d’affecter des rôles au principal du service.
  • Vous guidez tout au long d’un flux de travail pour créer et configurer un dépôt GitHub ou Azure DevOps et valider votre code de projet. Vous pouvez également choisir d’utiliser un référentiel existant.
  • Crée une connexion sécurisée entre Azure et votre référentiel.
  • Exécute l’action GitHub lorsque vous case activée dans le fichier de flux de travail.

Pour un contrôle plus précis sur ce processus ou si vous n’avez pas les rôles requis, vous pouvez configurer manuellement un pipeline.

Sélectionnez votre fournisseur de pipeline préféré pour continuer :

Autoriser GitHub à déployer sur Azure

Pour configurer le flux de travail, vous devez autoriser un principal de service à déployer sur Azure en votre nom à partir d’une action GitHub. azd crée le principal de service et les informations d’identification fédérées pour celle-ci.

  1. Exécutez la commande suivante pour créer le principal de service Azure et configurer le pipeline :

    azd pipeline config

    Cette commande crée éventuellement un dépôt GitHub et envoie (push) du code au nouveau dépôt.

    Remarque

    Par défaut, azd pipeline config utilise OpenID Connecter (OIDC), appelées informations d’identification fédérées. Si vous préférez ne pas utiliser OIDC, exécutez azd pipeline config --auth-type client-credentials.

    Les informations d’identification OIDC/fédérées ne sont pas prises en charge pour Terraform.

    En savoir plus sur la prise en charge d’OIDC dans azd.

  2. Fournissez les informations GitHub demandées.

  3. Lorsque vous y êtes invité à valider et envoyer (push) vos modifications locales pour démarrer une nouvelle exécution gitHub Actions, spécifiez y.

  4. Dans la fenêtre de terminal, affichez les résultats de la azd pipeline config commande. La azd pipeline config commande génère le nom du référentiel GitHub pour votre projet.

  5. À l’aide de votre navigateur, ouvrez le dépôt GitHub de votre projet.

  6. Sélectionnez Actions pour afficher le flux de travail en cours d’exécution.

    Capture d’écran du flux de travail GitHub en cours d’exécution.

Apporter et envoyer (push) une modification de code

  1. Dans le répertoire du /src/web/src/layout projet, ouvrez header.tsx.

  2. Recherchez la ligne <Text variant="xLarge">ToDo</Text>.

  3. Remplacez le littéral ToDo par myTodo.

  4. Enregistrez le fichier.

  5. Validez votre modification. La validation de la modification démarre le pipeline d’action GitHub pour déployer la mise à jour.

    Capture d’écran des étapes requises pour effectuer et valider la modification dans le fichier de test.

  6. À l’aide de votre navigateur, ouvrez le dépôt GitHub de votre projet pour voir les deux :

    • Votre validation
    • Validation de GitHub Actions en cours de configuration.

    Capture d’écran de votre modification validée dans GitHub.

  7. Sélectionnez Actions pour afficher la mise à jour de test reflétée dans le flux de travail.

    Capture d’écran du flux de travail GitHub en cours d’exécution après la mise à jour de test.

  8. Visitez l’URL du front-end web pour inspecter la mise à jour.

azd en tant qu’action GitHub

Ajouter azd en tant qu’action GitHub. Cette action va installer azd. Pour l’utiliser, vous pouvez ajouter ce qui suit :.github\workflows\azure-dev.yml

on: [push]

jobs:
   build:
      runs-on: ubuntu-latest
      steps:
         - name: Install azd
         uses: Azure/setup-azd@v0.1.0

Nettoyer les ressources

Quand vous n’avez plus besoin des ressources Azure créées dans cet article, exécutez la commande suivante :

azd down

Fonctionnalités avancées

Vous pouvez étendre la azd pipeline config commande pour des scénarios de modèle ou des exigences spécifiques, comme décrit dans les sections suivantes.

Secrets ou variables supplémentaires

Par défaut, azd définit des variables et des secrets pour le pipeline. Par exemple, la azd pipeline config commande crée les subscription idvariables de environment name pipeline et les variables de region pipeline chaque fois qu’elles s’exécutent. La définition du pipeline fait ensuite référence à ces variables :

env:
   AZURE_CLIENT_ID: ${{ vars.AZURE_CLIENT_ID }}
   AZURE_TENANT_ID: ${{ vars.AZURE_TENANT_ID }}
   AZURE_SUBSCRIPTION_ID: ${{ vars.AZURE_SUBSCRIPTION_ID }}
   AZURE_ENV_NAME: ${{ vars.AZURE_ENV_NAME }}
   AZURE_LOCATION: ${{ vars.AZURE_LOCATION }}

Lorsque le pipeline s’exécute, azd obtient les valeurs de l’environnement, qui est mappée aux variables et aux secrets. Selon le modèle, il peut y avoir des paramètres que vous pouvez contrôler à l’aide de variables d’environnement. Par exemple, une variable d’environnement nommée KEY_VAULT_NAME peut être définie pour définir le nom d’une ressource Key Vault dans l’infrastructure de modèle. Dans ce cas, la liste des variables et des secrets peut être définie par le modèle, à l’aide du azure.yaml. Par exemple, considérez la configuration suivante azure.yaml :

pipeline:
  variables:
    - KEY_VAULT_NAME
    - STORAGE_NAME
  secrets:
    - CONNECTION_STRING

Avec cette configuration, azd case activée si l’une des variables ou secrets a une valeur non vide dans l’environnement. azd crée ensuite une variable ou un secret pour le pipeline à l’aide du nom de la clé dans la configuration comme nom de la variable ou du secret, et la valeur non chaîne de l’environnement pour la valeur.

La définition du azure-dev.yaml pipeline peut ensuite référencer les variables ou secrets :

- name: Provision Infrastructure
   run: azd provision --no-prompt
   env:
      KEY_VAULT_NAME: ${{ variables.KEY_VAULT_NAME }}
      STORAGE_NAME: ${{ variables.STORAGE_NAME }}
      CONNECTION_STRING: ${{ secrets.CONNECTION_STRING }}

Remarque

Vous devez exécuter azd pipeline config après la mise à jour de la liste des secrets ou des variables dans azure.yaml azd pour réinitialiser les valeurs du pipeline.

Paramètres d’infrastructure

Prenons l’exemple bicep suivant :

@secure()
param BlobStorageConnection string

Le paramètre n’a pas de jeu BlobStorageConnection de valeurs par défaut. Il invite donc azd l’utilisateur à entrer une valeur. Toutefois, il n’existe aucune invite interactive pendant CI/CD. azd doit demander la valeur du paramètre lors de l’exécution azd pipeline config, enregistrer la valeur dans le pipeline, puis récupérer à nouveau la valeur lors de l’exécution du pipeline.

azd utilise un secret de pipeline appelé AZD_INITIAL_ENVIRONMENT_CONFIG pour enregistrer et définir automatiquement la valeur de tous les paramètres requis dans le pipeline. Vous devez uniquement référencer ce secret dans votre pipeline :

- name: Provision Infrastructure
   run: azd provision --no-prompt
   env:
      AZD_INITIAL_ENVIRONMENT_CONFIG: ${{ secrets.AZD_INITIAL_ENVIRONMENT_CONFIG }}

Lorsque le pipeline s’exécute, azd prend les valeurs des paramètres du secret, en supprimant la nécessité d’une invite interactive.

Remarque

Vous devez réexécuter azd pipeline config si vous ajoutez un nouveau paramètre.

Créer une définition de pipeline

Si votre azd modèle n’a pas encore de fichier de définition de pipeline CI/CD, vous pouvez en créer un vous-même. Une définition de pipeline CI/CD comporte généralement 4 sections principales :

  • déclencheur
  • autorisations
  • système d’exploitation ou pool
  • étapes à exécuter

Les exemples suivants montrent comment créer un fichier de définition et des configurations associées pour GitHub Actions et Azure Pipelines.

L’exécution azd dans GitHub Actions nécessite les configurations suivantes :

  • Accorder id-token: write et contents: read accéder aux étendues.
  • Installez l’action azd, sauf si vous utilisez une image Docker où azd elle est déjà installée.

Vous pouvez utiliser le modèle suivant comme point de départ pour votre propre définition de pipeline :

on:
  workflow_dispatch:
  push:
    # Run when commits are pushed to mainline branch (main or master)
    # Set this to the mainline branch you are using
    branches:
      - main
      - master

# Set this permission if you are using a Federated Credential.
permissions:
  id-token: write
  contents: read

jobs:
  build:
    runs-on: ubuntu-latest
    # azd build-in variables.
    # This variables are always set by `azd pipeline config`
    # You can set them as global env (apply to all steps) or you can add them to individual steps' environment
    env:
      AZURE_CLIENT_ID: ${{ vars.AZURE_CLIENT_ID }}
      AZURE_TENANT_ID: ${{ vars.AZURE_TENANT_ID }}
      AZURE_SUBSCRIPTION_ID: ${{ vars.AZURE_SUBSCRIPTION_ID }}
      AZURE_ENV_NAME: ${{ vars.AZURE_ENV_NAME }}
      AZURE_LOCATION: ${{ vars.AZURE_LOCATION }}
      ## Define the additional variables or secrets that are required globally (provision and deploy)
      # ADDITIONAL_VARIABLE_PLACEHOLDER: ${{ variables.ADDITIONAL_VARIABLE_PLACEHOLDER }}
      # ADDITIONAL_SECRET_PLACEHOLDER: ${{ secrets.ADDITIONAL_SECRET_PLACEHOLDER }}      
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      # using the install-azd action
      - name: Install azd
        uses: Azure/setup-azd@v1.0.0

      # # If you want to use azd-daily build, or install it from a PR, you can remove previous step and
      # # use the next one:
      # - name: Install azd - daily or from PR
      #  # Update this scrip based on the OS - pool of your pipeline. This example is for a linux pipeline installing daily build
      #  run: curl -fsSL https://aka.ms/install-azd.sh | bash -s -- --version daily
      #  shell: pwsh

      # azd set up Federated Credential by default. You can remove this step if you are using Client Credentials
      - name: Log in with Azure (Federated Credentials)
        if: ${{ env.AZURE_CLIENT_ID != '' }}
        run: |
          azd auth login `
            --client-id "$Env:AZURE_CLIENT_ID" `
            --federated-credential-provider "github" `
            --tenant-id "$Env:AZURE_TENANT_ID"
        shell: pwsh

      ## If you set up your pipeline with Client Credentials, remove previous step and uncomment this one
      # - name: Log in with Azure (Client Credentials)
      #   if: ${{ env.AZURE_CREDENTIALS != '' }}
      #   run: |
      #     $info = $Env:AZURE_CREDENTIALS | ConvertFrom-Json -AsHashtable;
      #     Write-Host "::add-mask::$($info.clientSecret)"

      #     azd auth login `
      #       --client-id "$($info.clientId)" `
      #       --client-secret "$($info.clientSecret)" `
      #       --tenant-id "$($info.tenantId)"
      #   shell: pwsh
      #   env:
      #     AZURE_CREDENTIALS: ${{ secrets.AZURE_CREDENTIALS }}

      - name: Provision Infrastructure
        run: azd provision --no-prompt
        env:
         #  # uncomment this if you are using infrastructure parameters
         #  AZD_INITIAL_ENVIRONMENT_CONFIG: ${{ secrets.AZD_INITIAL_ENVIRONMENT_CONFIG }}
         ## Define the additional variables or secrets that are required only for provision 
         #  ADDITIONAL_VARIABLE_PLACEHOLDER: ${{ variables.ADDITIONAL_VARIABLE_PLACEHOLDER }}
         #  ADDITIONAL_SECRET_PLACEHOLDER: ${{ secrets.ADDITIONAL_SECRET_PLACEHOLDER }}

      - name: Deploy Application
        run: azd deploy --no-prompt
        env:
         ## Define the additional variables or secrets that are required only for deploy
         #  ADDITIONAL_VARIABLE_PLACEHOLDER: ${{ variables.ADDITIONAL_VARIABLE_PLACEHOLDER }}
         #  ADDITIONAL_SECRET_PLACEHOLDER: ${{ secrets.ADDITIONAL_SECRET_PLACEHOLDER }}