Node.js CI/CD avec les actions GitHub et Heroku

L’intégration continue/déploiement continu est une pratique d’ingénierie logicielle qui aide les équipes à mieux collaborer et à améliorer l’ensemble de leurs logiciels. Avec GitHub Actions, vous pouvez facilement l’intégrer dans votre projet GitHub sans utiliser de plateforme externe.

Dans ce tutoriel, nous voyons comment vous pouvez utiliser GitHub Actions pour mettre en place un pipeline CI/CD pour votre projet.

Pour utiliser ce tutoriel, vous aurez besoin des éléments suivants :

• Node installé
• Connaissance de base de Node.js et Express
• Une bonne connaissance de Git
• Jest et Heroku seront utilisés, mais ce n’est pas obligatoire pour suivre le tutoriel.

Avant de nous plonger dans les actions GitHub pour CI/CD, comprenons ce qu’est l’intégration continue et le déploiement continu.

Qu’est-ce que l’intégration continue ?

L’intégration continue (CI) est une pratique d’ingénierie logicielle qui exige des commits fréquents dans un référentiel partagé. Vous vous êtes peut-être tellement habitué à cette pratique que vous vous demandez pourquoi il existe un terme pour la désigner.

Pour mieux comprendre, considérons l’inverse de l’IC. Avant le CI, les gens travaillaient sur des branches de fonctionnalités pendant des semaines ou des mois, puis essayaient de fusionner cette branche avec une branche principale. Pensez à tout ce qui pouvait mal se passer lors d’une telle fusion – conflits de fusion et échec des tests, pour n’en citer que quelques-uns.

L’intégration continue tente de prévenir tous ces problèmes en encourageant des mises à jour de code petites et fréquentes. Lorsqu’un code est déposé dans un référentiel, il peut être construit et testé en fonction des flux de travail configurés afin de s’assurer que le code n’introduit aucune erreur.

Qu’est-ce que le déploiement continu (CD) ?

Le déploiement continu signifie que les modifications du code sont automatiquement déployées/libérées dans un environnement de test ou de production dès qu’elles sont fusionnées. Cette notion est souvent confondue avec la livraison continue, car elles sont très similaires. La seule différence est que dans la livraison continue, une intervention humaine (par exemple, le clic d’un bouton) est nécessaire pour que les changements soient publiés. En revanche, dans le déploiement continu, tout se passe automatiquement. Dans la suite de cet article, nous ferons référence au CD comme au déploiement continu.

Présentons quelques avantages de CI/CD.

Les avantages du CI/CD

Voici d’autres avantages en plus de ceux déjà mentionnés ci-dessus :

• L’isolation des fautes est plus simple et plus rapide. Comme les changements sont plus petits, il est plus facile d’isoler les changements qui causent un bogue après le déploiement. Il est donc plus facile de corriger ou de revenir en arrière si nécessaire.
• Comme le CI/CD encourage les changements petits et fréquents, le temps de révision du code est plus court.
• Une partie importante du pipeline CI/CD est le test automatisé des flux critiques pour un projet. Il est ainsi plus facile de prévenir les changements susceptibles de casser ces flux en production.

Une meilleure qualité du code est assurée car vous pouvez configurer le pipeline pour tester les règles de linting.

Voyons maintenant comment nous pouvons utiliser les actions GitHub pour configurer un pipeline CI/CD pour un projet Node.js. Avant d’entrer dans le code, faisons un bref tour d’horizon des actions GitHub.

Que sont les actions GitHub ?

Selon la documentation de GitHub sur GitHub Actions, GitHub Actions est une plateforme d’intégration et de livraison continues (CI/CD) qui vous permet d’automatiser votre pipeline de construction, de test et de déploiement. Vous pouvez créer des flux de travail qui construisent et testent chaque demande de pull vers votre dépôt, ou qui déploient les demandes de pull fusionnées vers la production.

Cela signifie qu’avec GitHub Actions, vous pouvez configurer des pipelines CI/CD qui s’exécutent lorsque certaines actions sont effectuées sur un dépôt. Vous pouvez décider d’exécuter des tests pour chaque pull request (PR) créée ou fusionnée, vous pouvez déployer automatiquement les PR fusionnées, et vous pouvez même configurer un workflow pour ajouter les étiquettes appropriées lorsqu’une PR est créée.

Comment cela fonctionne-t-il ? Nous allons utiliser un exemple pour expliquer comment le configurer pour un référentiel.

Configuration des actions GitHub

Prenez note du répertoire dans lequel le fichier est créé : .github/workflows. Un workflow est un processus automatisé configurable qui exécute un ou plusieurs travaux. Vous pouvez voir que le fichier de flux de travail créé ici est un fichier YAML. Un flux de travail est défini par un fichier YAML dans votre répertoire .github/workflows et il est déclenché par un événement défini dans le fichier.

Donc, nous pouvons créer une fichier par exemple : .github/workflows/nodetesting.yml

# This is a basic workflow to help you get started with Actions
name: Node.js CI Testing

# Controls when the workflow will run
on:
  # Triggers the workflow on push or pull request events but only for the main branch
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

  # Allows you to run this workflow manually from the Actions tab
  workflow_dispatch:

# A workflow run is made up of one or more jobs that can run sequentially or in parallel
jobs:
  # This workflow contains a single job called "build"
  build:
    # The type of runner that the job will run on
    runs-on: ubuntu-latest

    # Steps represent a sequence of tasks that will be executed as part of the job
    steps:
      # Checks out your repository under $GITHUB_WORKSPACE, so your job can access it
      - uses: actions/checkout@v2

      # Runs a single command using the runners shell
      - name: Run a one-line script
        run: echo Hello, world!

      # Runs a set of commands using the runners shell
      - name: Run a multi-line script
        run: |
          echo Add other actions to build,
          echo test, and deploy your project.

Jobs

Une tâche est un ensemble d’étapes qu’un flux de travail doit exécuter sur le même exécutant. Il peut s’agir d’un script shell ou d’une action. Les étapes sont exécutées dans l’ordre dans le même runner et sont dépendantes les unes des autres. C’est une bonne chose car les données peuvent être partagées d’une étape à l’autre.

Les tâches sont exécutées en parallèle, mais vous pouvez également configurer une tâche pour qu’elle dépende d’une autre tâche. Par exemple, vous pouvez vouloir déployer un PR fusionné uniquement lorsque la construction a réussi ou que les tests ont été passés avec succès.

Exécutants (Runners)

Ceci indique le serveur sur lequel la tâche doit être exécutée. Il peut s’agir d’Ubuntu Linux, Microsoft Windows ou macOS, ou vous pouvez héberger votre propre exécuteur sur lequel la tâche doit être exécutée.

Dans l’exemple de flux de travail, nous voulons que le travail soit exécuté sur la dernière version d’Ubuntu :

# The type of runner that the job will run on
    runs-on: ubuntu-latest

Actions

Une action exécute une tâche complexe et répétitive. Il s’agit d’une application personnalisée pour la plateforme GitHub Actions. Les actions sont très importantes pour réduire la quantité de code nécessaire à la mise en place d’un flux de travail. Vous pouvez soit écrire une action, soit utiliser une action déjà existante sur la place de marché GitHub.

Voici un extrait d’une action utilisée dans l’exemple de flux de travail :

# Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
- uses: actions/checkout@v2

Pour notre application, nous devrons utiliser une action Node.js pour construire notre application Node et une action Heroku pour déployer notre application. Nous y reviendrons plus tard.

Pour l’instant, renommez le fichier à un nom de votre choix. Je vais nommer le mien en nodetesting.yml et m’y référer plus tard. Faites un commit de ce workflow.

Pour voir les Actions GitHub à l’œuvre, créons une application Node très simple dans le projet que nous venons de cloner. Si vous souhaitez ajouter GitHub Actions à un projet existant, vous pouvez sauter cette partie.

Mise en place du projet

Installons les dépendances dont nous avons besoin. Nous allons utiliser Express pour notre application et Jest et SuperTest pour tester l’application :

npm install express 
npm install jest supertest --save-dev

Création de l’application et ajout de tests

Ensuite, nous ajoutons les fichiers index.js et app.js à un répertoire src. Dans votre terminal, exécutez les commandes suivantes :

mkdir src
cd src
touch index.js app.js app.test.js

Ouvrez le fichier app.js créé et ajoutez le code suivant.

const express = require('express')
const app = express()

app.get('/test', (_req, res) => {
  res.status(200).send('Hello world')
})

module.exports = app

Dans le fichier index.js, ajoutez ce code :

const app =  require( "./app");
const PORT = process.env.PORT || 8015;

app.listen(PORT, () =>
  // eslint-disable-next-line no-console
  console.log(`The app listening at http://localhost:${PORT}`)
);

Ajoutons également un test pour le point de terminaison que nous venons de créer. Dans le fichier app.test.js, ajoutez le code suivant :

const app = require('./app')
const supertest = require('supertest')
const request = supertest(app)

describe('/test endpoint', () => {
  it('should return a response', async () => {
    const response = await request.get('/test')
    expect(response.status).toBe(200)
    expect(response.text).toBe('Hello world')
  })
})

Exécutez npm start et npm test pour vous assurer que tout fonctionne comme prévu.

Configuration du flux de travail

Revenons au fichier nodetesting.yml, ou le nom que vous avez donné au vôtre. Nous allons modifier ce fichier pour construire l’application et exécuter les tests chaque fois qu’une demande de tirage est fusionnée à la branche principale, et déployer cette application sur Heroku.

Donc dans ce fichier, changez :

  # Steps represent a sequence of tasks that will be executed as part of the job
    steps:
      # Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
      - uses: actions/checkout@v2

      # Runs a single command using the runners shell
      - name: Run a one-line script
        run: echo Hello, world!

      # Runs a set of commands using the runners shell
      - name: Run a multi-line script
        run: |
          echo Add other actions to build,
          echo test, and deploy your project.

Avec cela :

steps:
    - uses: actions/checkout@v2
    - name: Use Node.js
      uses: actions/setup-node@v2
      with: 
        node-version: "16.x"

    - name: Install dependencies
      run: npm install

    - name: Run test
      run: npm test

À ce stade, si nous poussons ceci vers notre branche principale, nous verrons cette action s’exécuter. Mais comme nous voulons aller un peu plus loin pour ajouter le déploiement automatique sur Heroku, nous allons ajouter une deuxième tâche à notre flux de travail.

Déploiement vers Heroku

Une fois de plus, nous n’avons pas besoin de construire l’action pour ce déploiement à partir de zéro. La place de marché GitHub nous sauve la mise. Nous allons donc retourner sur la place de marché et rechercher Deploy to Heroku. Vous pouvez décider d’utiliser l’action de votre choix en fonction de vos besoins. Si vous exécutez votre application dans un conteneur Docker, vous voudrez peut-être utiliser celles pour Docker.

Nous utiliserons la première action « Deploy to Heroku » d’AkhileshNS car nous déployons une simple application Node.js. Cliquez dessus pour voir comment l’utiliser.

Dans la section « Démarrage » (Getting Started), vous trouverez des détails sur la façon d’utiliser l’action.

Nous allons copier l’exemple de code dans la partie build, l’ajouter aux jobs, et le modifier pour qu’il réponde à nos besoins. Donc, ajoutez ceci au fichier nodetesting.yml :

  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: akhileshns/heroku-deploy@v3.12.12 # This is the action
        with:
          heroku_api_key: ${{secrets.HEROKU_API_KEY}}
          heroku_app_name: "YOUR APP's NAME" #Must be unique in Heroku
          heroku_email: "YOUR EMAIL"

Puisque nous avons déjà une tâche de construction, nous allons renommer cette tâche en deploy. De plus, nous avons besoin que cette tâche ne s’exécute que lorsque les tests se déroulent avec succès, donc pour l’empêcher de s’exécuter en parallèle avec la tâche de construction, nous ajouterons qu’elle dépend de la construction.

Le code ci-dessus sera modifié comme suit :

 deploy:
    runs-on: ubuntu-latest
    needs: [build]
    steps:
      - uses: actions/checkout@v2
      - uses: akhileshns/heroku-deploy@v3.12.12 
        with:
          heroku_api_key: ${{secrets.HEROKU_API_KEY}}
          heroku_app_name: "YOUR APP's NAME" #Must be unique in Heroku
          heroku_email: "YOUR EMAIL"

Maintenant, remarquez que pour que ce travail soit exécuté, nous avons besoin d’un compte Heroku. C’est là que vous obtiendrez HEROKU_API_KEY et un nom d’application Heroku. Si vous n’avez pas de compte, vous pouvez vous inscrire ici. Après l’inscription, ou si vous avez déjà un compte, vous pouvez obtenir votre HEROKU_API_KEY à partir des paramètres de votre compte. Cliquez sur l’image en haut à droite de la navigation pour accéder aux paramètres de votre compte. Faites défiler vers le bas jusqu’à Clé API pour copier votre clé API.

Pour que notre flux de travail ait accès à cette clé, nous devons l’ajouter aux Secrets du repo. Donc, dans votre dépôt Github, allez dans Settings > Secrets et cliquez sur Nouveau secret. Entrez HEROKU_API_KEY comme nom et collez la clé API copiée de Heroku comme valeur.

Après cela, pour nous assurer que le nom de notre application Heroku est unique et pour éviter que notre déploiement n’échoue, nous pouvons créer une nouvelle application sur Heroku. Sur votre tableau de bord, cliquez sur New et suivez les étapes pour créer l’application.

Copiez le nom de l’application et mettez à jour le flux de travail avec le nom de l’application créée et votre adresse e-mail Heroku.

Test du flux de travail

Nous sommes maintenant prêts à tester notre workflow. Pour s’assurer que tout est en place, voici ce que doit contenir le fichier nodetesting.yml. Comme il s’agit d’un fichier YAML, assurez-vous qu’il est correctement espacé :

name: Main
on:
  push:
    branches: [ main ]
  workflow_dispatch:
jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v2
      - name: Use Node.js
        uses: actions/setup-node@v2
        with: 
          node-version: "16.x"
      - name: Install dependencies
        run: npm install
      - name: Run test
        run: npm test

  deploy:
    runs-on: ubuntu-latest
    needs: [build]
    steps:
      - uses: actions/checkout@v2
      - uses: akhileshns/heroku-deploy@v3.12.12 
        with:
          heroku_api_key: ${{secrets.HEROKU_API_KEY}}
          heroku_app_name: "kilukru-node-app-express-jest"
          heroku_email: ${{secrets.HEROKU_USER_EMAIL}}

Commençons par commiter et pousser vers notre branche principale.

Si vous allez dans les Actions, vous verrez que votre push a déclenché l’exécution d’un workflow.

Vous pouvez cliquer sur le flux de travail pour obtenir des détails sur sa progression.

Vous pouvez voir sur l’image ci-dessus que la construction a réussi et que le déploiement est en cours. Remarquez également que la tâche de déploiement ne s’est exécutée qu’après la fin de la tâche de construction. Si tout va bien, vous obtiendrez un déploiement réussi comme celui ci-dessous.

Maintenant, voyons notre application déployée. Allez sur .herokuapp.com/test et vous devriez voir « Hello, world ! » sur l’écran.

Par exemple notre application est disponible sur l’URL : kilukru-node-app-express-jest.herokuapp.com/test

Bon travail pour être arrivé jusqu’ici.

Conclusion

Dans cet article, nous avons abordé ce qu’est le CI/CD et ses avantages. Nous avons également abordé les actions GitHub et utilisé un flux de travail simple pour montrer comment vous pouvez mettre en place un pipeline CI/CD avec celui-ci. Vous pouvez créer plusieurs flux de travail en fonction des besoins de votre référentiel. Par exemple, si vous travaillez sur un dépôt avec de nombreux contributeurs, vous pouvez décider de créer un flux de travail qui s’exécute lorsqu’une demande de pull vers la branche principale est créée, et un autre qui s’exécute lorsque la demande de pull est fusionnée.

L’un des avantages des actions GitHub est que vous n’avez pas à créer de toutes pièces les actions nécessaires à vos flux de travail. La place de marché propose déjà de nombreuses actions que vous pouvez utiliser ou personnaliser en fonction de vos besoins. Vous pouvez également créer des actions personnalisées qui sont spécifiques aux besoins de votre organisation. Tous ces éléments font des actions GitHub un outil passionnant à utiliser pour construire un pipeline CI/CD.

Merci de votre lecture et j’espère vraiment que ce tutoriel vous servira de guide pour démarrer avec GitHub Actions.

Pour une lecture plus approfondie, vous pouvez vous référer à la documentation officielle sur GitHub Actions.