Comprendre les travaux de workflow

7 minutes

Les flux de travail vous permettent d’automatiser les étapes de votre processus de déploiement. Votre processus peut inclure plusieurs groupes logiques de travaux que vous voulez exécuter. Dans cette unité, vous allez découvrir les travaux de workflow et comment les utiliser pour ajouter des processus de contrôle qualité à vos déploiements Bicep.

Présentation des travaux de workflow

Les travaux vous aident à diviser votre workflow en plusieurs blocs logiques. Chaque travail peut contenir une ou plusieurs étapes.

Diagramme qui montre un workflow contenant un seul travail. Le travail comporte quatre étapes.

Les travaux peuvent être utilisés dans votre workflow pour marquer une séparation des problématiques. Par exemple, quand vous travaillez avec du code Bicep, la validation du code est un problème distinct du déploiement de votre fichier Bicep. Quand vous utilisez un workflow automatisé, la génération et le test de votre code sont souvent appelés intégration continue (CI). Le déploiement de code dans un workflow automatisé est souvent appelé déploiement continu (CD).

Dans les tâches CI, vous vérifiez la validité des modifications apportées à votre code. Les travaux CI fournissent une assurance qualité. Ils peuvent être exécutés sans impacter votre environnement de production actif.

Dans de nombreux langages de programmation, le code doit être généré pour que quelqu’un puisse l’exécuter. Quand un fichier Bicep est déployé, il est converti, ou recompilé, du format Bicep au format JSON. Les outils effectuent ce processus automatiquement. Dans la plupart des cas, vous n’avez pas besoin de transformer manuellement le code Bicep en modèles JSON dans votre workflow. Nous utilisons néanmoins toujours le terme d’intégration continue quand nous parlons du code Bicep, car les autres parties de l’intégration continue s’appliquent toujours, comme la validation de votre code.

Une fois que l’exécution de vos tâches CI a été réussie, vous avez davantage confiance en la réussite du déploiement de vos modifications. Dans les travaux CD, vous déployez votre code sur chacun de vos environnements. Vous commencez en général par des environnements de test ou d’autres environnements hors production, puis vous passez aux environnements de production. Dans ce module, nous allons déployer sur un seul environnement. Dans un prochain module, vous apprendrez à étendre votre workflow de déploiement pour déployer le code sur plusieurs environnements, comme des environnements hors production et des environnements de production.

Par défaut, les travaux s’exécutent en parallèle. Vous pouvez contrôler le mode et le moment d’exécution de chaque travail. Par exemple, vous pouvez configurer vos travaux CD pour qu’ils s’exécutent seulement après l’exécution réussie de vos travaux CI. Vous pouvez aussi avoir plusieurs travaux CI qui doivent s’exécuter en séquence, par exemple pour générer votre code, puis le tester. Vous pouvez aussi inclure un travail de restauration appelé rollback qui s’exécute uniquement en cas d’échec des travaux de déploiement précédents.

« Shift Left »

L’utilisation de travaux vous permet de vérifier la qualité de votre code avant de le déployer. Ce processus est parfois appelé décalage à gauche.

Imaginez une chronologie des activités que vous effectuez quand vous écrivez du code. La chronologie commence par les phases de planification et de conception. Elle continue ensuite par les phases de génération et de test. Vous finissez par les phases de déploiement et de support de votre solution.

Graphique avec une chronologie sur l’axe horizontal, le coût sur l’axe vertical et une ligne indiquant que plus tard une erreur est identifiée dans le processus, plus le coût augmente.

Une règle bien établie dans le développement logiciel est que plus tôt vous identifiez une erreur dans le processus (c’est-à-dire à une étape la plus à gauche dans la chronologie), plus il est facile et rapide de la corriger et moins cela vous coûte cher. Plus tard vous identifiez une erreur dans votre processus, plus elle devient difficile et compliqué à résoudre.

L’objectif est donc de décaler la découverte des problèmes vers la gauche du diagramme précédent. Tout au long de ce module, vous verrez comment ajouter davantage de validation et de tests à votre workflow à mesure qu’il progresse.

Vous pouvez même ajouter la validation avant le début de votre déploiement. Quand vous utilisez des outils comme GitHub, les demandes de tirage (pull requests) représentent généralement les modifications qu’un membre de votre équipe veut apporter au code sur votre branche primaire. Il est utile de créer un autre workflow qui exécute automatiquement vos étapes CI pendant le processus de revue de la demande de tirage. Cette technique vous aide à vérifier que le code fonctionne toujours, même avec les modifications proposées. Si la validation réussit, vous pouvez avoir une certaine confiance dans le fait que la modification n’entraîne pas de problèmes une fois fusionnée avec votre branche principale. Si la vérification échoue, vous savez qu’il y a davantage de travail à effectuer avant que la demande de tirage soit prête pour la fusion. Dans un module ultérieur, vous en apprendrez davantage sur la configuration d’un processus de mise en production approprié à l’aide de demandes de tirage et de stratégies de création de branches.

Important

La validation et les tests automatisés sont efficaces seulement dans la mesure où les tests que vous écrivez le sont. Il est important de prendre en compte les éléments à tester et les étapes à effectuer pour garantir un déploiement correct.

Définir un travail de workflow

Chaque workflow doit contenir au moins un travail ; vous pouvez définir d’autres travaux si nécessaire. Par défaut, les travaux s’exécutent en parallèle. Le type de votre compte GitHub détermine le nombre de travaux exécutables simultanément lorsque vous utilisez des exécuteurs hébergés par GitHub.

Imaginez que vous avez créé un fichier Bicep que vous devez déployer deux fois : une fois sur l’infrastructure aux États-Unis et une fois sur l’infrastructure en Europe. Vous souhaitez également valider votre code Bicep dans votre workflow. Voici une illustration d’un workflow multitravail qui définit un processus similaire :

Diagramme montrant un workflow avec un travail Validate (validation), un travail Deploy US (déploiement aux États-Unis) et un travail Deploy Europe (déploiement en Europe) qui s’exécutent en parallèle.

Notez que cet exemple comporte trois travaux. Le travail de validation, Validate, est similaire à un travail CI. Ensuite, les travaux de déploiement Deploy US et Deploy Europe s’exécutent. Chaque travail déploie le code dans l’un des environnements. Par défaut, les travaux s’exécutent en parallèle.

Voici de quelle façon les travaux sont définis dans un fichier YAML de workflow :

name: learn-github-actions
on: [push]
jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - run: echo "Here is where you'd perform the validation steps."
  deployUS: 
    runs-on: windows-latest
    steps:
      - run: echo "Here is where you'd perform the steps to deploy to the US region."
  deployEurope: 
    runs-on: ubuntu-latest
    steps:
      - run: echo "Here is where you'd perform the steps to deploy to the European region."

Contrôler la séquence des travaux

Vous pouvez ajouter des dépendances entre les travaux pour changer l’ordre. En reprenant l’exemple précédent, vous souhaiterez probablement valider votre code avant d’exécuter vos travaux de déploiement, comme ceci :

Diagramme montrant un workflow avec un travail Validate (validation), un travail Deploy US (déploiement aux États-Unis) et un travail Deploy Europe (déploiement en Europe), où les deux travaux de déploiement s’exécutent en parallèle.

Vous pouvez spécifier les dépendances entre les travaux en utilisant le mot clé needs :

name: learn-github-actions
on: [push]
jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - run: echo "Here is where you'd perform the validation steps."
  deployUS: 
    runs-on: windows-latest
    needs: validate
    steps:
      - run: echo "Here is where you'd perform the steps to deploy to the US region."
  deployEurope: 
    runs-on: ubuntu-latest
    needs: validate
    steps:
      - run: echo "Here is where you'd perform the steps to deploy to the European region."

Quand vous utilisez le mot clé needs, le workflow attend que le travail dépendant se termine correctement avant de commencer le travail suivant. Si le flux de travail détecte que toutes les dépendances pour plusieurs tâches ont été satisfaites, il peut exécuter ces tâches en parallèle.

Remarque

En réalité, les travaux s’exécutent en parallèle uniquement s’il y a suffisamment d’exécuteurs pour exécuter plusieurs travaux en même temps. Le nombre d’exécuteurs hébergés par GitHub que vous pouvez utiliser dépend du type de votre compte GitHub. Vous pouvez acheter un autre plan de compte GitHub si vous avez besoin d’exécuter davantage de travaux parallèles.

Vous souhaiterez parfois exécuter un travail spécifique en cas d’échec d’un travail précédent. Voici un exemple de workflow différent. Si le déploiement échoue, un travail de restauration appelé rollback s’exécute immédiatement après :

Diagramme montrant un workflow avec un travail Deploy et une condition qui spécifie qu’un échec de ce travail entraîne l’exécution du travail Rollback.

Vous utilisez le mot clé if pour spécifier une condition qui doit être remplie avant qu’un travail s’exécute :

name: learn-github-actions
on: [push]
jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - run: echo "Here is where you'd perform the validation steps."
  deploy: 
    runs-on: windows-latest
    needs: validate
    steps:
      - run: echo "Here is where you'd perform the steps to deploy."
  rollback: 
    runs-on: ubuntu-latest
    needs: deploy
    if: ${{ failure() }}
    steps:
      - run: echo "Here is where you'd perform the steps to roll back a failure."

Dans l’exemple précédent, quand tout se passe bien, le workflow exécute d’abord le travail Test, puis il exécute le travail Deploy. Il ignore le travail Rollback. Toutefois, si le travail Test ou Deploy échoue, le workflow exécute le travail Rollback. Vous allez en découvrir davantage sur la restauration plus loin dans ce module.

Travaux de déploiement Bicep

Un workflow de déploiement Bicep classique contient plusieurs travaux. À mesure que le flux de travail progresse dans les tâches, l’objectif est d’avoir de plus en plus confiance en la réussite des travaux ultérieurs. Voici les travaux courants dans un workflow de déploiement Bicep :

Diagramme qui montre un workflow de déploiement Bicep avec cinq travaux : Lint, Validate, Preview, Deploy et Smoke Test.

Lint (linting) : utilisez le linter Bicep pour vérifier que le fichier Bicep est bien formé et ne contient pas d’erreurs évidentes.
Validate (validation) : utilisez le processus de validation préalable d’Azure Resource Manager pour détecter les problèmes qui peuvent se produire quand vous déployez.
Préversion : utilisez la commande de simulation pour valider la liste des modifications qui seront appliquées à votre environnement Azure. Demandez à une personne de vérifier manuellement les résultats de la simulation et d’approuver le workflow pour continuer.
Deploy (déploiement) : soumettez votre déploiement à Resource Manager et attendez qu’il se termine.
Test d’acceptation de build : exécutez les vérifications post-déploiement de base sur certaines des ressources importantes que vous avez déployées. Ces vérifications sont appelées tests de détection de fumée d’infrastructure.

Votre organisation peut avoir une séquence de travaux différente, ou vous devrez peut-être intégrer vos déploiements Bicep dans un workflow qui déploie d’autres composants. Une fois que vous avez compris le fonctionnement des travaux, vous pouvez concevoir un workflow répondant à vos besoins.

Chaque travail s’exécute sur une nouvelle instance d’exécuteur qui démarre à partir d’un environnement propre. Par conséquent, dans chaque travail, vous devrez généralement extraire le code source comme première étape. Vous devrez aussi vous connecter à votre environnement Azure dans chaque travail qui interagit avec Azure.

Tout au long de ce module, vous allez en découvrir davantage sur ces travaux et vous allez créer progressivement un workflow qui inclut chaque travail. Vous allez aussi découvrir :