Réutilisez vos actions et évitez la duplication dans votre projet en utilisant GitHub Actions

Lorsque vous configurez votre intégration continue et votre déploiement continue, vous avez toujours plusieurs environnements à cibler. Par exemple:

• dev
• staging
• production

Votre application sera déployée dans chaque environnement avec les mêmes scripts. La seule chose qui change, ce sont les paramètres des workflows. Vous vous retrouverez donc probablement avec de la duplication. Alors comment mutualiser vos actions pour gagner du temps ?

Cas d’usage

Vous disposez d’une application Web que vous buildez, puis déployez sur chaque environnement. Votre GitHub workflow situé dans .github/workflows/main.yml doit ressembler à ceci :

Tout d’abord, vous buildez le projet et le packagez pour produire un artefact :

name: Reusable templates

on:
  push:
    branches: [main]

jobs:

build_and_package:
  steps:
    - name: checkout branch
      uses: actions/checkout@v2
    
    - run: echo Your build commands here
      shell: bash

    - run: echo Then your package commands here
      shell: bash

Puis, vous mettez tous les jobs pour déployer votre application après :

deploy_dev:
  runs-on: ubuntu-latest
  name: Deploy to dev
  needs: build_and_package

  steps:
    - name: Checkout the code
      uses: actions/checkout@v2

    - run: |
        echo Run on env : Dev
      shell: bash

    # Other steps here...

    - run: |
        echo Add your actions to deploy to the correct environment using ${{ secrets.DEV_DEPLOYMENT_TOKEN }}
      shell: bash

deploy_staging:
  runs-on: ubuntu-latest
  name: Deploy to staging
  needs: deploy_staging

  steps:
    - name: Checkout the code
      uses: actions/checkout@v2

    - run: |
        echo Run on env : Staging
      shell: bash

    # Other steps here...

    - run: |
        echo Add your actions to deploy to the correct environment using ${{ secrets.STAGING_DEPLOYMENT_TOKEN }}
      shell: bash

# Same process for production, eluded for clarity

Comme vous pouvez le voir, nous copions-collons le job et remplaçons les secrets pour correspondre à l’environnement spécifique. Comment pouvons-nous améliorer ceci ?

Créer des composites locaux

Pour éviter la duplication des jobs de déploiement, nous pouvons utiliser le concept des GitHub Action appelé composite. L’idée est que vous pouvez créer une partie générique de votre workflow afin de gagner du temps et ainsi éviter les erreurs.

Alors créons-en un pour la section de déploiement. Dans nos workflows, créons un dossier appelé templates et à l’intérieur un autre appelé deploy_to_cloud. Ensuite, dans ce dernier dossier, ajoutons un fichier appelé action.yml.

Le nom du fichier est important si vous ne le spécifiez pas comme cela votre composite ne sera pas trouvé. C’est pourquoi il est important de mettre ce fichier dans un dossier avec un nom explicite.

Vous aurez donc cette arborescence de fichiers :

|- .github
    |- workflows
        |- templates
            |- deploy_to_cloud
                |- action.yml
        |- main.yml

Voici notre fichier action.yml :

name: "Deploy to the cloud"
description: "Reusable actions to deploy to the cloud"

inputs:
  name:
    description: 'Name'
    required: true
  deployment-token:
    description: 'Deployment token'
    required: true

runs:
  using: "composite"
  steps: 
    - run: |
        echo Run on env : ${{ inputs.name }}
      shell: bash

    # Other steps here...

    - run: |
        echo Add your actions to deploy to the correct environment using ${{ inputs.deployment-token }}
      shell: bash

Comme vous pouvez le voir, nous avons deux variables d’entrée, une pour le nom de l’environnement et une pour un token de déploiement. Ensuite on définit ce fichier comme un composite avant de définir les différentes étapes. Enfin, on met exactement les mêmes actions mais on utilise les variables d’inputs donc c’est totalement génériques.

Appliquer le composite

Il est maintenant temps d’appliquer le composite dans le workflow !

deploy_dev:
  runs-on: ubuntu-latest
  name: Deploy to staging
  needs: build_and_package
  steps:
    - name: Checkout the code
      uses: actions/checkout@v2

    - name: Deploy to cloud
      uses: ./.github/workflows/templates/deploy_to_cloud
      with:
        name: 'Dev'
        deployment-token: ${{ secrets.DEV_DEPLOYMENT_TOKEN }}

deploy_staging:
      
  runs-on: ubuntu-latest
  name: Deploy to staging
  needs: deploy_dev
  
  steps:
    - name: Checkout the code
      uses: actions/checkout@v2

    - name: Deploy to cloud
      uses: ./.github/workflows/templates/deploy_to_cloud
      with:
        name: 'Staging'
        deployment-token: ${{ secrets.STAGING_DEPLOYMENT_TOKEN }}

# Same process for production, eluded for clarity

Comme vous pouvez le voir ci-dessus, la première étape importante que nous faisons est actions/checkout@v2 pour pouvoir accéder à ce composite et ensuite nous pouvons l’utiliser directement avec les valeurs spécifiques à l’environnement comme paramètres.

Touche finale

Avec cette technique vous pouvez désormais capitaliser sur votre projet et commencer à créer votre propre banque de templates pour tous vos projets. Pour en savoir plus, consultez mon précédent tutoriel à ce sujet.

Happy coding !

N'hésitez pas à me suivre sur Twitter pour ne pas rater mon prochain tutoriel !