Partager via


Tutoriel : Déployer des environnements dans CI/CD à l’aide de GitHub et d’environnements de déploiement Azure

Dans ce tutoriel, vous allez apprendre à intégrer des environnements de déploiement Azure dans votre pipeline CI/CD. Vous pouvez utiliser n’importe quel fournisseur GitOps prenant en charge CI/CD, comme GitHub Actions, Azure Arc, GitLab ou Jenkins.

L’intégration continue et livraison continue (CI/CD) est une approche de développement logiciel qui aide les équipes à automatiser le processus de création, de test, puis de déploiement des modifications logicielles. L’intégration continue et livraison continue CI/CD vous permet de publier les modifications logicielles plus fréquemment et en toute confiance.

Vous utilisez un workflow qui comporte trois branches : main, dev et test.

  • La branche main est toujours considérée comme une branche de production.
  • Vous créez des branches de fonctionnalité depuis la branche main.
  • Vous créez des demandes de tirage (pull requests) pour fusionner des branches de fonctionnalités dans main.

Ce workflow est un petit exemple pour les besoins de ce tutoriel. Les flux de travail réels peuvent être plus complexes.

Avant de commencer ce tutoriel, vous pouvez vous familiariser avec les ressources et les concepts des environnements de déploiement en examinant les concepts clés pour les environnements de déploiement Azure.

Dans ce tutoriel, vous allez apprendre à :

  • Créer et configurer un centre de développement
  • Création d’un coffre de clés
  • Créer, puis configurer un référentiel GitHub
  • Connecter le catalogue à votre centre de développement
  • Configurer des identités de déploiement
  • Configurer des environnements GitHub
  • test du pipeline CI/CD

Prérequis

1. Créer, puis configurer un centre de développement

Dans cette section, vous allez créer un centre de développement azure Deployment Environments et un projet avec trois types d’environnement : Dev, Test et Prod.

  • Le type d’environnement Prod contient l’environnement de production unique.
  • Un nouvel environnement est créé dans Dev pour chaque branche de fonctionnalité.
  • Un nouvel environnement est créé dans Test pour chaque demande de tirage.

1.1 Configurer Azure CLI

Pour commencer, connectez-vous à Azure. Exécutez la commande suivante et suivez les invites pour terminer le processus d’authentification.

az login

Ensuite, installez l’extension Azure devcenter pour Azure CLI.

az extension add --name devcenter --upgrade

Maintenant que l’extension actuelle est installée, inscrivez l’espace de noms Microsoft.DevCenter.

az provider register --namespace Microsoft.DevCenter

Conseil

Tout au long de ce tutoriel, vous allez enregistrer plusieurs valeurs comme variables d’environnement pour les utiliser ultérieurement. Vous pouvez également enregistrer ces valeurs ailleurs pour vous assurer qu’elles sont disponibles si nécessaire.

Obtenez l’ID de votre utilisateur, puis définissez-le sur une variable d’environnement pour une utilisation ultérieure :

MY_AZURE_ID=$(az ad signed-in-user show --query id -o tsv)

Récupérer l’ID d’abonnement de votre abonnement actuel.

AZURE_SUBSCRIPTION_ID=$(az account show --query id --output tsv)

Récupérez l’ID de votre tenant actuel.

AZURE_TENANT_ID=$(az account show --query tenantId --output tsv)

Définissez les variables d’environnement suivantes :

LOCATION="eastus"
AZURE_RESOURCE_GROUP=<resourceGroupName>
AZURE_DEVCENTER=<devcenterName>
AZURE_PROJECT=<projectName>
AZURE_KEYVAULT=<keyVaultName>

Remarque

Vous devez utiliser un nom global unique de coffre de clés. Sinon, vous pouvez obtenir l’erreur suivante : Code: VaultAlreadyExists Message: The vault name 'mykeyvaultname' is already in use. Vault names are globally unique so it is possible that the name is already taken.

1.2 Créer un centre de développement

Un centre de développement est une collection de projets et d’environnements qui ont des paramètres similaires. Les centres de développement donnent accès à un catalogue de modèles et d’artefacts qui permettent de créer des environnements. Les centres de développement permettent également de gérer l’accès aux environnements et aux projets.

Créez un groupe de ressources.

az group create \
  --name $AZURE_RESOURCE_GROUP \
  --location $LOCATION

Créez un centre de développement.

az devcenter admin devcenter create \
  --name $AZURE_DEVCENTER \
  --identity-type SystemAssigned \
  --resource-group $AZURE_RESOURCE_GROUP \
  --location $LOCATION

La commande précédente génère JSON. Enregistrez les valeurs des paramètres id et identity.principalId comme variables d’environnement à utiliser ultérieurement.

AZURE_DEVCENTER_ID=<id>
AZURE_DEVCENTER_PRINCIPAL_ID=<identity.principalId>

1.3 Attribuer le rôle propriétaire de l’identité du centre de développement lors de l’abonnement

Un centre de développement a besoin d’autorisations pour attribuer des rôles sur les abonnements associés aux types d’environnement.

Pour réduire la complexité inutile, dans ce tutoriel, vous allez utiliser un seul abonnement pour le centre de développement et tous les types d’environnement. En pratique, le centre de développement et les abonnements de déploiement cible seront probablement des abonnements distincts avec des stratégies différentes appliquées.

az role assignment create \
  --scope /subscriptions/$AZURE_SUBSCRIPTION_ID \
  --role Owner \
  --assignee-object-id $AZURE_DEVCENTER_PRINCIPAL_ID \
  --assignee-principal-type ServicePrincipal

1.4 Créer les types d’environnement

Au niveau du centre de développement, les types d’environnement définissent les environnements que les équipes de développement peuvent créer, comme les environnements de développement, de test, de bac à sable, de préproduction ou de production.

Créez trois nouveaux types d’environnement : Dev, Test et Prod.

az devcenter admin environment-type create \
  --name Dev \
  --resource-group $AZURE_RESOURCE_GROUP \
  --dev-center $AZURE_DEVCENTER
az devcenter admin environment-type create \
  --name Test \
  --resource-group $AZURE_RESOURCE_GROUP \
  --dev-center $AZURE_DEVCENTER
az devcenter admin environment-type create \
  --name Prod \
  --resource-group $AZURE_RESOURCE_GROUP \
  --dev-center $AZURE_DEVCENTER

1.5 Créer un projet

Un projet est le point d’accès pour l’équipe de développement. Chaque projet est associé à un centre de développement.

Créer un nouveau projet.

az devcenter admin project create \
  --name $AZURE_PROJECT \
  --resource-group $AZURE_RESOURCE_GROUP \
  --location $LOCATION \
  --dev-center-id $AZURE_DEVCENTER_ID

La commande précédente génère JSON. Enregistrez la valeur id comme variable d’environnement pour l’utiliser ultérieurement.

AZURE_PROJECT_ID=<id>

Attribuez-vous le rôle Administration du projet DevCenter sur le projet.

az role assignment create \
  --scope "$AZURE_PROJECT_ID" \
  --role "DevCenter Project Admin" \
  --assignee-object-id $MY_AZURE_ID \
  --assignee-principal-type User

1.6 Créer des types d’environnement de projet

Au niveau du projet, les ingénieurs de plateforme spécifient les types d’environnement appropriés pour l’équipe de développement.

Créez un type d’environnement de projet pour chacun des types d’environnement que vous avez créés dans le centre de développement.

az devcenter admin project-environment-type create \
  --name Dev \
  --roles "{\"b24988ac-6180-42a0-ab88-20f7382dd24c\":{}}" \
  --deployment-target-id /subscriptions/$AZURE_SUBSCRIPTION_ID \
  --resource-group $AZURE_RESOURCE_GROUP \
  --location $LOCATION \
  --project $AZURE_PROJECT \
  --identity-type SystemAssigned \
  --status Enabled
az devcenter admin project-environment-type create \
  --name Test \
  --roles "{\"b24988ac-6180-42a0-ab88-20f7382dd24c\":{}}" \
  --deployment-target-id /subscriptions/$AZURE_SUBSCRIPTION_ID \
  --resource-group $AZURE_RESOURCE_GROUP \
  --location $LOCATION \
  --project $AZURE_PROJECT \
  --identity-type SystemAssigned \
  --status Enabled
az devcenter admin project-environment-type create \
  --name Prod \
  --roles "{\"b24988ac-6180-42a0-ab88-20f7382dd24c\":{}}" \
  --deployment-target-id /subscriptions/$AZURE_SUBSCRIPTION_ID \
  --resource-group $AZURE_RESOURCE_GROUP \
  --location $LOCATION \
  --project $AZURE_PROJECT \
  --identity-type SystemAssigned \
  --status Enabled

2. Créer un coffre de clés

Dans cette section, vous allez créer un coffre de clés. Vous utiliserez ce coffre de clés ultérieurement dans le tutoriel pour enregistrer un jeton d’accès personnel depuis GitHub.

az keyvault create \
  --name $AZURE_KEYVAULT \
  --resource-group $AZURE_RESOURCE_GROUP \
  --location $LOCATION \
  --enable-rbac-authorization true

De nouveau, enregistrez le paramètre id de la sortie JSON de la commande précédente comme variable d’environnement.

AZURE_KEYVAULT_ID=<id>

Donnez-vous le rôle key Vault Administration istrator sur le nouveau coffre de clés.

az role assignment create \
  --scope $AZURE_KEYVAULT_ID \
  --role "Key Vault Administrator" \
  --assignee-object-id $MY_AZURE_ID \
  --assignee-principal-type User

Attribuez l’identité du centre de développement au rôle d’utilisateur des secrets Key Vault.

az role assignment create \
  --scope $AZURE_KEYVAULT_ID \
  --role "Key Vault Secrets User" \
  --assignee-object-id $AZURE_DEVCENTER_PRINCIPAL_ID \
  --assignee-principal-type ServicePrincipal

3. Créer, puis configurer un référentiel GitHub

Dans cette section, vous allez créer un référentiel GitHub pour stocker un catalogue. Les Environnements de déploiement Azure prennent en charge les référentiels GitHub et Azure DevOps. Dans ce tutoriel, vous allez utiliser GitHub.

3.1 Créer un référentiel GitHub

Dans cette étape, vous allez créer un référentiel dans votre compte GitHub qui a une structure de répertoires prédéfinis, des branches et des fichiers. Ces éléments sont générés depuis un exemple de référentiel de modèles.

  1. Utilisez ce lien pour générer un nouveau référentiel GitHub depuis l’exemple de modèle.

    Screenshot showing the GitHub create repository from template page.

  2. Si vous n’avez pas de compte GitHub payant, définissez votre référentiel sur Public.

  3. Sélectionnez Create repository from template (Créer un dépôt à partir du modèle).

  4. Sous l’onglet Actions, vous remarquerez que l’action Créer un environnement échoue. Ce comportement est normal et vous pouvez passer à l’étape suivante.

3.2 Protéger la branche main du référentiel

Vous pouvez protéger les branches importantes en définissant des règles de protection de branche. Les règles de protection définissent si les collaborateurs peuvent supprimer ou forcer l’envoi (push) à la branche. Ils définissent également des exigences pour tous les envois (push) vers la branche, comme la transmission de vérifications d’état ou un historique de validation linéaire.

Notes

Les branches protégées sont disponibles dans les référentiels publics avec GitHub Free et GitHub Free pour les organisations, et dans les référentiels publics et privés avec GitHub Pro, GitHub Team, GitHub Enterprise Cloud et GitHub Enterprise Server. Pour plus d’informations, consultez les produits de GitHub.

  1. Si cette page n’est pas déjà ouverte, accédez à la page principale de votre référentiel.

  2. Sous le nom de votre dépôt, sélectionnez Settings (Paramètres) . Si vous ne voyez pas l’onglet Paramètres, sélectionnez le menu déroulant ... , puis sélectionnez Paramètres.

    Screenshot showing the GitHub repository page with settings highlighted.

  3. Dans la section Code et automatisation de la barre latérale, sélectionnez Branches.

    Screenshot showing the settings page, with branches highlighted.

  4. Sous Règles de protection des branches, sélectionnez Ajouter une règle de protection des branches.

    Screenshot showing the branch protection rule page, with Add branch protection rule highlighted.

  5. Sous Modèle de nom de branche, entrez main.

    Screenshot showing the branch name pattern text box, with main highlighted.

  6. Sous Protéger les branches correspondantes, sélectionnez Exiger une demande de tirage (pull request) avant de fusionner.

    Screenshot showing protect matching branches with Require a pull request before merging selected and highlighted.

  7. Si vous le souhaitez, vous pouvez activer d’autres règles de protection.

  8. Sélectionnez Create (Créer).

3.3 Configurer les variables de référentiel

Notes

Les variables de configuration de GitHub Actions sont à la version bêta et peuvent être modifiées.

  1. Dans la section Sécurité de la barre latérale, sélectionnez Secrets et variables, puis Actions.

    Screenshot showing the Security section of the sidebar with Actions highlighted.

  2. Sélectionnez l’onglet Variables.

  3. Pour chaque élément du tableau :

    1. Sélectionnez Nouvelle variable de référentiel.
    2. Dans le champ Nom, entrez le nom de la variable.
    3. Dans le champ Valeur, entrez la valeur décrite dans le tableau.
    4. Sélectionnez Ajouter une variable.
    Nom de la variable Valeur de variable
    AZURE_DEVCENTER Nom de votre centre de développement
    AZURE_PROJECT Nom de votre projet
    AZURE_CATALOG Définir sur « Environnements »
    AZURE_CATALOG_ITEM Défini sur « FunctionApp »
    AZURE_SUBSCRIPTION_ID L'identifiant de votre abonnement Azure.
    AZURE_TENANT_ID VOTRE ID de locataire Azure

    Screenshot showing the variables page with the variables table.

3.4 Créer un jeton d’accès personnel GitHub

Ensuite, créez un jeton d’accès personnel affiné pour permettre à votre centre de développement d’environnements de déploiement Azure de se connecter à votre référentiel et de consommer le catalogue d’environnements.

Remarque

Les jetons d’accès personnels affinés sont actuellement en version bêta et susceptibles d’être modifiés. Pour laisser des commentaires, veuillez consulter la discussion relative aux commentaires.

  1. Dans le coin supérieur droit d’une page sur GitHub.com, sélectionnez votre photo de profil, puis sélectionnez Paramètres.

  2. Dans la barre latérale gauche, sélectionnez Paramètres de développeur.

  3. Dans la barre latérale gauche, sous Jetons d’accès personnels, sélectionnez Jetons affinés, puis Générer un nouveau jeton.

    Screenshot showing the GitHub personal access token options, with Fine-grained tokens and Generate new token highlighted.

  4. Dans la page Nouveau jeton d’accès personnel affiné, sous Nom du jeton, entrez un nom pour le jeton.

  5. Sous Expiration, sélectionnez une date d’expiration pour le jeton.

  6. Sélectionnez votre utilisateur GitHub sous Propriétaire de la ressource.

  7. Sous Accès au référentiel, sélectionnez Sélectionner uniquement les référentiels, puis dans la liste déroulante Référentiels sélectionnés, recherchez, puis sélectionnez le référentiel que vous avez créé.

    Screenshot showing GitHub repository access options, with Only select repositories highlighted.

  8. Sous Autorisations, sélectionnez Autorisations du référentiel, puis remplacez Contenu par Lecture seule.

    Screenshot showing GitHub repository permissions with Contents highlighted.

  9. Sélectionnez Generate token.

  10. Copiez et enregistrez votre jeton d’accès personnel maintenant. Vous ne pouvez pas le voir à nouveau.

3.5 Enregistrer votre jeton d’accès personnel dans le coffre de clés

Ensuite, enregistrez le jeton d’accès personnel en tant que secret de coffre de clés nommé pat.

az keyvault secret set \
    --name pat \
    --vault-name $AZURE_KEYVAULT \
    --value <personalAccessToken>

4. Connecter le catalogue à votre centre de développement

Dans les environnements de déploiement Azure, un catalogue est un référentiel qui contient un ensemble de définitions d’environnements. Les éléments de catalogue sont constitués d’un modèle d’infrastructure en tant que code (IaC) et d’un fichier d’environnement qui agit comme manifeste. Le modèle définit l’environnement et le fichier d’environnement fournit les métadonnées sur le modèle. Les équipes de développement utilisent des définitions d’environnement du catalogue pour créer des environnements.

Le modèle que vous avez utilisé pour créer votre référentiel GitHub contient un catalogue dans le dossier Environnements.

Ajouter le catalogue à votre centre de développement

Dans la commande suivante, remplacez < Organization/Repository > par le nom de votre organisation GitHub et de votre référentiel.

az devcenter admin catalog create \
    --name Environments \
    --resource-group $AZURE_RESOURCE_GROUP \
    --dev-center $AZURE_DEVCENTER \
    --git-hub path="/Environments" branch="main" secret-identifier="https://$AZURE_KEYVAULT.vault.azure.net/secrets/pat" uri="https://github.com/< Organization/Repository >.git"

5. Configurer des identités de déploiement

OpenID Connect avec GitHub Actions est une méthode d’authentification qui utilise des jetons de courte durée pour offrir une sécurité renforcée. Nous vous recommandons d’utiliser cette méthode pour authentifier GitHub Actions auprès d’Azure.

Vous pouvez également authentifier un principal de service directement à l’aide d’un secret, mais cela est hors de portée pour ce didacticiel.

5.1. Générer des identités de déploiement

  1. Inscrivez les applications et les principaux de service Microsoft Entra pour chacun des trois types d’environnement.

    Créez l’application Microsoft Entra pour Dev.

    az ad app create --display-name "$AZURE_PROJECT-Dev"
    

    Cette commande génère une sortie JSON avec un id que vous utilisez lors de la création d’informations d’identification fédérées avec l’API Graph et un appId (également appelé ID client).

    Définissez les variables d’environnement suivantes :

    DEV_AZURE_CLIENT_ID=<appId>
    DEV_APPLICATION_ID=<id>
    

    Répétez le test.

    az ad app create --display-name "$AZURE_PROJECT-Test"
    
    TEST_AZURE_CLIENT_ID=<appId>
    TEST_APPLICATION_ID=<id>
    

    Et pour Prod.

    az ad app create --display-name "$AZURE_PROJECT-Prod"
    
    PROD_AZURE_CLIENT_ID=<appId>
    PROD_APPLICATION_ID=<id>
    
  2. Créez un principal de service pour chaque application.

    Exécutez la commande suivante pour créer un principal de service pour Dev.

     az ad sp create --id $DEV_AZURE_CLIENT_ID
    

    Cette commande génère une sortie JSON avec un id différent, qui sera utilisée à l’étape suivante.

    Définissez les variables d’environnement suivantes :

    DEV_SERVICE_PRINCIPAL_ID=<id>
    

    Répétez le test.

     az ad sp create --id $TEST_AZURE_CLIENT_ID
    
    TEST_SERVICE_PRINCIPAL_ID=<id>
    

    Et pour Prod.

     az ad sp create --id $PROD_AZURE_CLIENT_ID
    
    PROD_SERVICE_PRINCIPAL_ID=<id>
    
  3. Exécutez les commandes suivantes pour créer des informations d’identification d’identité fédérée pour votre application Active Directory.

    Dans chacune des trois commandes suivantes, remplacez < Organization/Repository > par le nom de votre organisation GitHub et de votre référentiel.

    Créez les informations d’identification d’identité fédérée pour Dev.

    az rest --method POST \
        --uri "https://graph.microsoft.com/beta/applications/$DEV_APPLICATION_ID/federatedIdentityCredentials" \
        --body '{"name":"ADEDev","issuer":"https://token.actions.githubusercontent.com","subject":"repo:< Organization/Repository >:environment:Dev","description":"Dev","audiences":["api://AzureADTokenExchange"]}'
    

    Pour test.

    az rest --method POST \
        --uri "https://graph.microsoft.com/beta/applications/$TEST_APPLICATION_ID/federatedIdentityCredentials" \
        --body '{"name":"ADETest","issuer":"https://token.actions.githubusercontent.com","subject":"repo:< Organization/Repository >:environment:Test","description":"Test","audiences":["api://AzureADTokenExchange"]}'
    

    Et pour Prod.

    az rest --method POST \
        --uri "https://graph.microsoft.com/beta/applications/$PROD_APPLICATION_ID/federatedIdentityCredentials" \
        --body '{"name":"ADEProd","issuer":"https://token.actions.githubusercontent.com","subject":"repo:< Organization/Repository >:environment:Prod","description":"Prod","audiences":["api://AzureADTokenExchange"]}'
    

5.2 Attribuer des rôles aux identités de déploiement

  1. Attribuez à chaque identité de déploiement le rôle Lecteur sur le projet.

    az role assignment create \
        --scope "$AZURE_PROJECT_ID" \
        --role Reader \
        --assignee-object-id $DEV_SERVICE_PRINCIPAL_ID \
        --assignee-principal-type ServicePrincipal
    
    az role assignment create \
        --scope "$AZURE_PROJECT_ID" \
        --role Reader \
        --assignee-object-id $TEST_SERVICE_PRINCIPAL_ID \
        --assignee-principal-type ServicePrincipal
    
    az role assignment create \
        --scope "$AZURE_PROJECT_ID" \
        --role Reader \
        --assignee-object-id $PROD_SERVICE_PRINCIPAL_ID \
        --assignee-principal-type ServicePrincipal
    
  2. Attribuez à chaque identité de déploiement le rôle Utilisateur des environnements de déploiement à son type d’environnement correspondant.

    az role assignment create \
        --scope "$AZURE_PROJECT_ID/environmentTypes/Dev" \
        --role "Deployment Environments User" \
        --assignee-object-id $DEV_SERVICE_PRINCIPAL_ID \
        --assignee-principal-type ServicePrincipal
    
    az role assignment create \
        --scope "$AZURE_PROJECT_ID/environmentTypes/Test" \
        --role "Deployment Environments User" \
        --assignee-object-id $TEST_SERVICE_PRINCIPAL_ID \
        --assignee-principal-type ServicePrincipal
    
    az role assignment create \
        --scope "$AZURE_PROJECT_ID/environmentTypes/Prod" \
        --role "Deployment Environments User" \
        --assignee-object-id $PROD_SERVICE_PRINCIPAL_ID \
        --assignee-principal-type ServicePrincipal
    

6. Configurer des environnements GitHub

Avec des environnements GitHub, vous pouvez configurer des environnements avec des règles de protection et des secrets. Un travail de workflow qui fait référence à un environnement doit respecter les règles de protection de l’environnement avant d’exécuter les secrets de l’environnement ou d’y accéder.

Créez des environnements Dev, Test et Prod qui correspondent aux types d’environnement dans le projet Environnements de déploiement Azure.

Remarque

Des environnements, des secrets d’environnement et des règles de protection d’environnement sont disponibles dans les dépôts publics pour tous les produits. Pour accéder aux environnements, secrets d’environnement et branches de déploiement dans des référentiels privés ou internes , vous devez utiliser GitHub Pro, GitHub Team ou GitHub Enterprise. Pour accéder à d’autres règles de protection d’environnement dans des référentiels privés ou internes, vous devez utiliser GitHub Enterprise. Pour plus d’informations, consultez les produits de GitHub.

6.1 Créer l’environnement de développement

  1. Sur GitHub, accédez à la page principale de votre dépôt.

  2. Sous le nom de votre dépôt, sélectionnez Settings (Paramètres) . Si vous ne voyez pas l’onglet Paramètres, sélectionnez le menu déroulant ... , puis sélectionnez Paramètres.

  3. Dans la barre latérale de gauche, sélectionnez Environnements.

  4. Sélectionnez Nouvel environnement, entrez Dev comme nom d’environnement, puis sélectionnez Configurer l’environnement.

    Screenshot showing the Environments Add pane, with the environment name Dev, and Configure Environment highlighted.

  5. Sous Secrets d’environnement, sélectionnez Ajouter un secret, puis entrez AZURE_CLIENT_ID dans la zone Nom.

    Screenshot showing the Environment Configure Dev pane, with Add secret highlighted.

  6. Pour valeur, entrez l’ID client (appId) de l’application *Dev**Microsoft Entra que vous avez créée précédemment (enregistrée en tant que variable d’environnement $DEV_AZURE_CLIENT_ID ).

    Screenshot of the Add secret box with the name AZURE CLIENT ID, the value set to an ID number, and add secret highlighted.

  7. Sélectionnez Ajouter un secret.

6.2 Créer l’environnement de test

Revenez à la page principale Environnements en sélectionnant Environnements dans la barre latérale gauche.

  1. Sélectionnez Nouvel environnement, entrez Test comme nom d’environnement, puis sélectionnez Configurer l’environnement.

  2. Sous Secrets d’environnement, sélectionnez Ajouter un secret, puis entrez AZURE_CLIENT_ID dans la zone Nom.

  3. Dans la zone Valeur, entrez l’identifiant client (appId) de l’application Microsoft Entra Test que vous avez créée précédemment (enregistrée en tant que variable d’environnement $TEST_AZURE_CLIENT_ID).

  4. Sélectionnez Ajouter un secret.

6.3 Créer l’environnement Prod

De nouveau, revenez à la page principale Environnements en sélectionnant Environnements dans la barre latérale gauche.

  1. Sélectionnez Nouvel environnement, entrez Prod comme nom d’environnement, puis sélectionnez Configurer l’environnement.

  2. Sous Secrets d’environnement, sélectionnez Ajouter un secret, puis entrez AZURE_CLIENT_ID dans la zone Nom.

  3. Dans la zone Valeur, entrez l’identifiant client (appId) de l’application Microsoft Entra Prod que vous avez créée précédemment (enregistrée en tant que variable d’environnement $PROD_AZURE_CLIENT_ID).

  4. Sélectionnez Ajouter un secret.

Ensuite, définissez-vous comme réviseur requis pour cet environnement. Lors d’une tentative de déploiement sur Prod, GitHub Actions attend une approbation avant de démarrer. Alors qu’un travail attend l’approbation, il a un état d’attente. Si un travail n’est pas approuvé dans les 30 jours, il échouera automatiquement.

Pour plus d’informations sur les environnements et les approbations requises, consultez Utilisation d’environnements pour le déploiement.

  1. Sélectionnez Required reviewers.

  2. Recherchez, puis sélectionnez votre utilisateur GitHub. Vous pouvez entrer jusqu’à six personnes ou équipes. Seul l’un des réviseurs requis doit approuver le travail pour qu’il continue.

  3. Sélectionnez Enregistrer les règles de protection.

Enfin, configurez main comme branche de déploiement :

  1. Dans la liste déroulante Branches de déploiement, choisissez Branches sélectionnées.

  2. Sélectionnez Ajouter une règle de branche de déploiement et entrez main le modèle de nom de branche.

  3. Sélectionnez Ajouter une règle.

7. Tester le pipeline CI/CD

Dans cette section, vous allez apporter des modifications au référentiel, puis tester le pipeline CI/CD.

7.1 Cloner le référentiel

  1. Dans votre terminal, accédez à un dossier où vous souhaitez cloner votre référentiel en local.

  2. Clonez le référentiel. Dans la commande suivante, veillez à remplacer < Organization/Repository > par le nom de votre organisation GitHub et de votre référentiel.

    git clone https://github.com/< Organization/Repository >.git
    
  3. Accédez au répertoire cloné.

    cd <repository>
    
  4. Ensuite, créez une branche, puis publiez-la à distance.

    git checkout -b feature1
    
    git push -u origin feature1
    

    Un nouvel environnement spécifique à cette branche est créé dans Azure.

  5. Sur GitHub, accédez à la page principale de votre dépôt nouvellement créé.

  6. Sous le nom de votre dépôt, sélectionnez Settings (Paramètres) .

    Un nouveau workflow Créer un environnement doit apparaître en cours d’exécution.

7.2 Apporter une modification au code

  1. Ouvrez le référentiel cloné en local dans VS Code.

  2. Dans l’ADE . Dossier du didacticiel , apportez une modification à un fichier.

  3. Enregistrez vos modifications.

7.3 Envoyer (push) vos modifications pour mettre à jour l’environnement

  1. Indexez, puis envoyez (push) vos modifications à la branche feature1.

    git add .
    git commit -m '<commit message>'
    git push
    
  2. Dans la page Actions de votre référentiel, un nouveau workflow Mettre à jour l’environnement apparaît en cours d’exécution.

7.4 Créer une demande de tirage (pull request)

  1. Créez une demande main <- feature1de tirage GitHub .

  2. Dans la page Actions de votre référentiel, vous voyez qu’un nouveau flux de travail est démarré pour créer un environnement spécifique à la demande de tirage à l’aide du type d’environnement de test.

7.5 Fusionner la demande de tirage

  1. Sur GitHub, accédez à la demande de tirage (pull request) que vous avez créée.

  2. Fusionner la demande de tirage.

    Vos modifications sont publiées dans l’environnement de production, les environnements de branche et de demande de tirage (pull request) sont supprimés.

Nettoyer les ressources

Si vous n’avez pas l’intention d’utiliser les ressources que vous avez créées, supprimez-les pour éviter la facturation de frais supplémentaires. Si vous avez déployé l’exemple d’application dans un autre groupe de ressources, vous pouvez répéter les étapes suivantes.

Pour supprimer des ressources à l’aide du Portail Azure :

  1. Sélectionnez le bouton du menu en haut à gauche, puis Groupes de ressources.

  2. Dans la liste, sélectionnez le groupe de ressources créé.

  3. Sélectionnez Supprimer le groupe de ressources.

  4. Entrez le nom du groupe de ressources. Puis sélectionnez Supprimer.

Pour supprimer des ressources à l’aide d’Azure CLI, entrez la commande suivante :

az group delete --name <my-dev-center-rg>

N’oubliez pas que la suppression du groupe de ressources supprime toutes les ressources qu’il contient.