Intégration continue (CI)

Introduction

Imaginez que vous écrivez un livre avec une grande équipe. Chaque fois qu’une personne propose un nouveau chapitre, vous devez vérifier les fautes d’orthographe et les incohérences dans l’intrigue. Faire cela manuellement est épuisant.

En développement logiciel, nous résolvons ce problème grâce à l’intégration continue (CI). La CI vérifie automatiquement les modifications dès que possible, généralement en installant les dépendances, en exécutant les tests et en validant le projet après chaque mise à jour.

L’idée essentielle est d’obtenir un retour rapide. Les problèmes sont plus faciles à corriger lorsqu’ils sont détectés juste après une modification plutôt que plusieurs jours plus tard.

C’est pour cette raison que la CI constitue généralement la première couche d’automatisation mise en place par les équipes. Elle protège la branche principale en transformant chaque push en contrôle automatique de la qualité.

Dans ce lab, vous allez construire ce filet de sécurité pour une application Node.js simple. Vous allez :

Créer une petite application qui effectue des calculs simples.
Écrire un test pour vérifier que le calcul est correct.
Configurer GitHub Actions pour exécuter automatiquement ce test à chaque push de code.
Provoquer volontairement une erreur afin d’observer comment le filet de sécurité la détecte.

Prérequis

Ce lab s’appuie sur le lab précédent. Nous allons continuer à utiliser le dépôt github-actions-basics que vous avez créé.

Préparer le projet Node.js

Commençons par créer du code à tester. Nous allons créer une toute petite application Node.js. Si vous n’êtes pas programmeur, ne vous inquiétez pas : tout le code nécessaire vous est fourni.

Accédez au répertoire du projet. Comme il s’agit d’un nouvel environnement de lab, nous devons télécharger à nouveau notre dépôt.

cd ~/project
git clone https://github.com/your-username/github-actions-basics.git
cd github-actions-basics

Remarque : pensez à remplacer your-username par votre véritable nom d’utilisateur GitHub.

Nous devons créer trois fichiers pour simuler un projet réel. Nous utiliserons la commande cat, qui permet de créer rapidement des fichiers contenant directement du contenu depuis la ligne de commande.

1. La « recette » (package.json)

Ce fichier indique à l’ordinateur ce qu’est notre projet et quels outils il nécessite. Nous indiquons ici que notre projet dépend d’un outil de test appelé jest.

cat > package.json << EOF
{
  "name": "ci-demo",
  "version": "1.0.0",
  "scripts": {
    "test": "jest"
  },
  "dependencies": {
    "jest": "^29.7.0"
  }
}
EOF

2. Le « plat » (index.js)

Il s’agit du code réel de notre application. C’est une fonction simple qui additionne deux nombres.

cat > index.js << EOF
function sum(a, b) {
  return a + b;
}
module.exports = sum;
EOF

3. Le « test de dégustation » (index.test.js)

Il s’agit de notre test automatisé. Il vérifie que l’addition de 1 et 2 donne bien 3.

cat > index.test.js << EOF
const sum = require('./index');

test('adds 1 + 2 to equal 3', () => {
  expect(sum(1, 2)).toBe(3);
});
EOF

Maintenant que nous avons créé les fichiers, nous devons les enregistrer sur GitHub. Exécutez les commandes Git standard pour envoyer votre travail.

git add .
git commit -m "Add Node.js project files"
git push

GitHub peut vous demander de vous connecter à nouveau. Utilisez votre nom d’utilisateur et votre Personal Access Token (PAT), comme précédemment.

Créer le workflow CI

Nous devons maintenant indiquer à notre assistant robot comment tester ce code. Nous allons créer un nouveau fichier de workflow nommé ci.yml dans le répertoire standard .github/workflows.

touch .github/workflows/ci.yml

Ouvrez ce fichier dans l’éditeur nano.

nano .github/workflows/ci.yml

Ajoutez la configuration suivante. Nous expliquerons les nouveaux éléments ci-dessous.

name: Node.js CI

on: [push]

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v3
        with:
          node-version: 16

Nous introduisons ici un nouveau mot-clé puissant : uses.

Il s’agit d’un mécanisme important de GitHub Actions. Au lieu d’écrire manuellement chaque étape du shell, les workflows composent souvent des actions réutilisables qui regroupent des tâches courantes, comme l’extraction du code, la configuration d’un langage ou l’envoi d’artefacts.

Imaginez que uses télécharge une compétence dans le cerveau du robot. Au lieu d’écrire des scripts complexes depuis zéro, nous pouvons utiliser des actions préconçues par d’autres personnes.

actions/checkout@v4 : cette action standard indique au robot : « Télécharge mon code ». Sans elle, l’espace de travail du robot serait vide.
actions/setup-node@v3 : cette action installe Node.js sur le runner. Nous lui transmettons également une version précise (16) afin de garantir la cohérence de l’environnement.

Enregistrez le fichier, puis quittez l’éditeur (Ctrl+X, Y, Enter).

Ajouter les étapes d’installation et de test

Nous avons le code, extrait avec l’étape checkout, ainsi que les outils, avec Node.js. Nous devons maintenant exécuter le test.

Dans l’écosystème Node.js, deux commandes standard permettent de le faire :

npm install : télécharge toutes les dépendances listées dans votre package.json, comme l’outil de test jest.
npm test : exécute le script de test défini dans votre package.json.

Ensemble, ces étapes représentent le cœur de la CI : préparer l’environnement, installer les dépendances et valider le code dans un runner propre avant de considérer la modification comme saine.

Ajoutons ces étapes à notre workflow. Ouvrez à nouveau .github/workflows/ci.yml.

nano .github/workflows/ci.yml

Ajoutez ces deux étapes à la fin du fichier. Vérifiez que leur indentation correspond à celle des étapes précédentes.

- name: Install dependencies
  run: npm install

- name: Run tests
  run: npm test

Votre fichier complet doit ressembler à ceci :

name: Node.js CI

on: [push]

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v3
        with:
          node-version: 16

      - name: Install dependencies
        run: npm install

      - name: Run tests
        run: npm test

Enregistrez le fichier, puis quittez l’éditeur.

Activez maintenant votre filet de sécurité en envoyant ce fichier sur GitHub.

git add .
git commit -m "Add CI pipeline"
git push

Accédez à votre dépôt sur GitHub et cliquez sur l’onglet Actions. Vous devriez voir un nouveau workflow nommé « Node.js CI » en cours d’exécution. Lorsqu’il se termine, une coche verte apparaît. Cela signifie que votre code fonctionne !

CI Pipeline

Provoquer un échec de compilation

Un filet de sécurité n’est utile que s’il vous rattrape lorsque vous tombez. Provoquons volontairement une erreur dans notre code afin d’observer le système de CI en action.

Nous allons modifier le fichier de test pour lui faire dire quelque chose de faux. Nous allons prétendre que 1 + 2 doit être égal à 4.

Ouvrez index.test.js avec nano.

nano index.test.js

Remplacez la valeur attendue dans le test : changez 3 en 4.

const sum = require("./index");

test("adds 1 + 2 to equal 3", () => {
  expect(sum(1, 2)).toBe(4); // CHANGED 3 to 4
});

Enregistrez le fichier et quittez l’éditeur. Effectuez ensuite un commit et envoyez cette « erreur ».

git add .
git commit -m "Intentionally break the test"
git push

Revenez immédiatement à l’onglet Actions sur GitHub. Observez l’exécution du nouveau workflow.

En quelques instants, l’exécution devrait échouer. Une icône X rouge apparaît à côté du commit. C’est le système de CI qui vous avertit : « Arrêtez ! Quelque chose ne va pas ! »

Cliquez sur l’exécution qui a échoué, puis sur la tâche build. Développez l’étape Run tests pour afficher le journal d’erreur :

Error: expect(received).toBe(expected) // Object.is equality

Expected: 4
Received: 3

Ce simple X rouge permet aux développeurs d’économiser d’innombrables heures en détectant les erreurs dès qu’elles surviennent, plutôt que plusieurs jours ou plusieurs semaines plus tard.

CI Pipeline Failed

Résumé

Dans ce lab, vous avez créé un pipeline d’intégration continue de niveau professionnel.

Vous avez appris :

Comment définir la « recette » d’un projet avec package.json.
Comment utiliser le mot-clé uses pour installer des outils puissants comme actions/checkout et actions/setup-node.
Comment automatiser les tests afin que chaque modification du code soit vérifiée par un robot.
Pourquoi le « X rouge » constitue un filet de sécurité pour votre code.

Dans le prochain lab, nous apprendrons comment prendre du code fonctionnel et le conditionner pour le rendre accessible au monde entier !