Gérer les similitudes entre les environnements en utilisant des workflows réutilisables

5 minutes

Quand vous déployez vos changements dans plusieurs environnements, les étapes impliquées dans le déploiement sur chaque environnement sont similaires, voire identiques. Dans cette unité, vous apprenez à concevoir vos workflows pour éviter les répétitions et permettre la réutilisation de votre code de workflow.

Déploiement sur plusieurs environnements

Après avoir parlé avec vos collègues de l’équipe de site web, vous décidez d’utiliser le workflow suivant pour le site web de votre entreprise de jouets :

Diagramme montrant une série de travaux de workflow et incluant les déploiements de test et de production.

Le workflow exécute le linter Bicep pour vérifier que le code Bicep est valide et suit les bonnes pratiques.

Comme le linting se déroule sur le code Bicep sans connexion à Azure, le nombre d’environnements que vous utilisez pour le déploiement n’a pas d’importance. Il s’exécute une seule fois.
Le workflow déploie le code dans l’environnement de test et nécessite :
1. Exécution de la validation préalable d’Azure Resource Manager.
2. Déploiement du code Bicep.
3. Exécution de certains tests sur votre environnement de test.
Si une partie du workflow échoue, le workflow entier s’arrête pour vous permettre d’investiguer et de résoudre le problème. En revanche, si tout fonctionne, votre workflow continue le déploiement dans votre environnement de production :
1. Le workflow ajoute une phase d’aperçu, qui exécute l’opération de simulation sur votre environnement de production pour lister les changements à effectuer sur vos ressources Azure de production. L’opération de simulation valide également votre déploiement et vous n’avez donc pas besoin d’exécuter une phase de validation séparée pour votre environnement de production.
2. Le workflow est mis en pause pour la validation manuelle.
3. Si l’approbation est reçue, le workflow exécute le déploiement et des tests d’acceptation de build sur votre environnement de production.

Certaines de ces tâches sont répétées entre vos environnements de test et de production, tandis que d’autres sont exécutées uniquement pour des environnements spécifiques :

Tâche	Environnements
Lint	Ni l’un, ni l’autre : le linting ne fonctionne pas sur un environnement
Valider	Test uniquement
Préversion	Production uniquement
Déployer	Les deux environnements
Test d’acceptation de build	Les deux environnements

Quand vous devez répéter des étapes dans votre workflow, il n’est pas très formateur de copier et coller vos définitions d’étape. Quand vous dupliquez le code de votre workflow, des éléments peuvent facilement se désynchroniser et vous pouvez faire sans le savoir de légères erreurs. Par la suite, quand vous devez effectuer un changement dans une étape, vous devez vous souvenir de l’appliquer à plusieurs endroits. Une meilleure pratique consiste à utiliser des workflows réutilisables.

Workflows réutilisables

GitHub Actions vous permet de créer des sections réutilisables de définitions de workflow en créant un fichier YAML de workflow séparé qui définit des étapes ou des travaux. Vous pouvez créer des fichiers YAML pour réutiliser des parties de workflow plusieurs fois dans le même workflow ou dans plusieurs workflows. Le workflow que vous réutilisez est un workflow appelé et le workflow qui l’intègre est un workflow appelant. Conceptuellement, ils se rapprochent des modules Bicep.

Quand vous créez un workflow réutilisable, vous utilisez le déclencheur workflow_call pour indiquer à GitHub Actions que le workflow peut être appelé par d’autres workflows. Voici un exemple de base de workflow réutilisable, enregistré dans un fichier nommé script.yml :

on:
  workflow_call:

jobs:
  say-hello:
    runs-on: ubuntu-latest
    steps:
    - run: |
        echo Hello world!

Dans le workflow appelant, vous référencez le workflow appelé en ajoutant le mot clé uses: et en spécifiant le chemin du workflow appelé dans le dépôt actuel :

on: 
  workflow_dispatch:

jobs:
  job:
    uses: ./.github/workflows/script.yml

Vous pouvez également référencer un fichier de définition de workflow dans un autre dépôt.

Entrées et secrets des workflows appelés

Vous pouvez utiliser des entrées et des secrets pour faciliter la réutilisation de vos workflows appelés, car vous pouvez autoriser de petites différences dans vos workflows chaque fois que vous les utilisez.

Quand vous créez un workflow appelé, vous pouvez indiquer ses entrées et secrets en haut du fichier :

on:
  workflow_call:
    inputs:
      environmentType:
        required: true
        type: string
    secrets:
      AZURE_CLIENT_ID:
        required: true
      AZURE_TENANT_ID:
        required: true
      AZURE_SUBSCRIPTION_ID:
        required: true

Vous pouvez définir autant d’entrées et de secrets que nécessaire. Toutefois, tout comme les paramètres Bicep, essayez de ne pas abuser des entrées de workflow. Vos workflows doivent pouvoir être facilement réutilisables par quelqu’un d’autre, sans avoir à spécifier trop de paramètres.

Les entrées peuvent avoir plusieurs propriétés, notamment :

Le nom de l’entrée, que vous utilisez pour référencer l’entrée dans vos définitions de flux de travail.
Le type de l’entrée. Les entrées prennent en charge les valeurs de chaîne, de nombreet booléennes.
La valeur par défaut de l’entrée, qui est facultative. Si vous ne spécifiez pas de valeur par défaut, vous devez en fournir une quand le workflow est utilisé dans un workflow appelant.

Les secrets ont des noms, mais ils n’ont pas de types ou de valeurs par défaut.

Dans l’exemple, le workflow définit une entrée de chaîne obligatoire nommée environmentType et trois secrets obligatoires nommés AZURE_CLIENT_ID, AZURE_TENANT_ID et AZURE_SUBSCRIPTION_ID.

Dans votre workflow, vous utilisez une syntaxe spéciale pour référencer la valeur du paramètre, comme dans cet exemple :

jobs:
  say-hello:
    runs-on: ubuntu-latest
    steps:
    - run: |
        echo Hello ${{ inputs.environmentType }}!

Vous passez la valeur des entrées à un workflow appelé en utilisant le mot clé with. Vous devez définir les valeurs de chaque entrée dans la section with. Vous ne pouvez pas utiliser le mot clé env pour référencer les variables d’environnement d’un workflow. Vous passez la valeur des secrets à un workflow appelé en utilisant le mot clé secrets.

on: 
  workflow_dispatch:

permissions:
  id-token: write
  contents: read

jobs:
  job-test:
    uses: ./.github/workflows/script.yml
    with:
      environmentType: Test
    secrets:
      AZURE_CLIENT_ID: ${{ secrets.AZURE_CLIENT_ID_TEST }}
      AZURE_TENANT_ID: ${{ secrets.AZURE_TENANT_ID }}
      AZURE_SUBSCRIPTION_ID: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

  job-production:
    uses: ./.github/workflows/script.yml
    with:
      environmentType: Production
    secrets:
      AZURE_CLIENT_ID: ${{ secrets.AZURE_CLIENT_ID_PRODUCTION }}
      AZURE_TENANT_ID: ${{ secrets.AZURE_TENANT_ID }}
      AZURE_SUBSCRIPTION_ID: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

Utiliser des identités de charge de travail à partir de workflows appelés

Quand vous travaillez avec des workflows appelés, vous définissez souvent certaines de vos actions de déploiement dans plusieurs fichiers de définition de workflow. Vous devez accorder l’autorisation au workflow de l’appelant, ce qui permet ensuite à chaque workflow appelé d’accéder à l’identité du workflow et de s’authentifier auprès d’Azure :

on: 
  workflow_dispatch:

permissions:
  id-token: write
  contents: read

jobs:
  job-test:
    uses: ./.github/workflows/script.yml
    with:
      environmentType: Test
    secrets:
      AZURE_CLIENT_ID: ${{ secrets.AZURE_CLIENT_ID_TEST }}
      AZURE_TENANT_ID: ${{ secrets.AZURE_TENANT_ID }}
      AZURE_SUBSCRIPTION_ID: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

  job-production:
    uses: ./.github/workflows/script.yml
    with:
      environmentType: Production
    secrets:
      AZURE_CLIENT_ID: ${{ secrets.AZURE_CLIENT_ID_PRODUCTION }}
      AZURE_TENANT_ID: ${{ secrets.AZURE_TENANT_ID }}
      AZURE_SUBSCRIPTION_ID: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

Conditions

Vous pouvez utiliser des conditions de workflow pour spécifier si une étape ou un travail doivent s’exécuter en fonction d’une règle que vous spécifiez. Vous pouvez combiner des entrées et des conditions de flux de travail pour personnaliser votre processus de déploiement dans de nombreuses situations.

Par exemple, imaginez que vous définissez un workflow qui exécute des étapes de script. Vous voulez réutiliser le modèle pour chacun de vos environnements. Quand vous déployez votre environnement de production, vous voulez exécuter une autre étape. Voici comment y parvenir en utilisant la condition if sur l’étape :

jobs:
  say-hello:
    runs-on: ubuntu-latest
    steps:
    - run: |
        echo Hello ${{ inputs.environmentType }}!

    - run: |
        echo This step only runs for production deployments.
      if: inputs.environmentType == 'Production'

La condition se traduit ici par : si la valeur du paramètre environmentType est égale à « Production », exécutez les étapes.

Bien que les conditions ajoutent de la flexibilité à votre workflow, s’il y en a trop, cela peut compliquer votre workflow et le rendre plus difficile à comprendre. Si vous avez de nombreuses conditions dans un workflow, vous pouvez envisager de le recommencer.