GitHub Actions : comment automatiser le déploiement d’un site statique

Comme expliqué dans cet article : les sites statiques, c’est bien ! Pour plein de raisons ! Mais le problème, c’est qu’un site statique c’est…

STATIQUE !!!

Concrètement, cela signifie que même si vous utilisez un CMS headless, à chaque fois que vous ajoutez du contenu ou même corrigez une coquille, il vous faudra faire un build et redéployer votre site…

Heureusement, il existe aujourd’hui différentes solutions pour automatiser le processus :

• des services spécialisés dans l’hébergement de sites statiques comme Vercel ou Netlify permettent de facilement automatiser le déploiement sans rien avoir à configurer ;
• avec un peu plus de configuration, les différentes plateformes de versionnage (GitHub et Gitlab notamment) proposent leur propre outil d’intégration continue et déploiement continu (GitHub actions, Gitlab CI/CD);
• enfin, les outils de CI/CD externes, permettent d’installer une pipeline avec n’importe quel hébergement ou service cloud et s’intègrent avec n’importe quel gestionnaire de code;

GitHub Actions

Ici, nous allons nous intéresser à GitHub Actions : l’outil CI/CD intégré de GitHub. L’idée est simple : lorsqu’un évènement a lieu dans notre dépôt GitHub, il s’agira de déclencher… bah une ACTION !

La première chose à faire pour utiliser GitHub Action est de pousser votre code vers un répertoire GitHub.

On va ensuite créer un workflow. Un workflow est un processus que l’on va définir via un fichier yaml qui sera déposé dans le dossier .github/workflows de votre projet.
Ce workflow sera composé d’évènements (events) et de tâches (jobs). Le but du jeu étant de définir quelles tâches seront exécutées lorsque tel évènement a lieu. Les tâches peuvent-elles mêmes être composées d‘étapes qui peuvent être de simples scripts shell ou des actions (blocs de code réutilisables qui peuvent être faits maison ou provenir de la GitHub marketplace).

Configurer les secrets dans GitHub

Pour que GitHub Actions puisse déposer les fichiers sur notre serveur, il va avoir besoin de la configuration FTP. On va donc configurer ces secrets dans notre dépôt GitHub :
Dans votre dépôt : settings => Security => Secrets and variables => Actions => New Repository Secret
Et on ajoute les trois secrets suivants :

• FTP_HOST : l’adresse du serveur ftp
• FTP_USERNAME: l’identifiant de l’utilisateur de votre serveur FTP
• FTP_PASSWORD : le mot de passe pour accéder à votre serveur FTP

Nous utiliserons ces secrets dans notre fichier yaml.

Rédiger le fichier yaml

Ce que nous voudrions dans notre cas, c’est déclencher un processus de déploiement en production à chaque fois que nous pousserons du code sur notre branche principale. Nous allons donc créer un fichier production.yml dans le dossier .github/workflows en y insérant le code suivant :

name: Production Deploy
on:
  push:
    branches:
      - "main"
  workflow_dispatch:
jobs:
  web-deploy-on-prod:
    name: Deploy on production
    runs-on: ubuntu-latest
    steps:
      - name: Get latest code
        uses: actions/checkout@v4
        with:
          ref: "main"

      - name: Use Node.js 22
        uses: actions/setup-node@v4
        with:
          node-version: "22"

      - name: 📥 Install dependencies
        run: npm install -f

      - name: 🔨 Build Project
        run: npm run build

      - name: 📂 Sync files
        uses: SamKirkland/FTP-Deploy-Action@v4.3.5
        with:
          server: ${{ secrets.FTP_HOST }}
          username: ${{ secrets.FTP_USERNAME }}
          password: ${{ secrets.FTP_PASSWORD }}
          local-dir: ./public/
          server-dir: ./www/

Ce qu’il se passe ici :

1. On nomme workflow Production Deploy
2. On programme le déclenchement du workflow sur l’évènement push de la branche main
3. On crée un job dont l’id sera web-deploy
4. Ce job sera exécuté sur une machine virtuelle ubuntu
5. On définit ensuite les steps dont on aura besoin :
   • Get latest code : Cette étape est une action nous permettant de nous placer sur la branche désirée
   • Use Node.js 22 : Cette étape est également une action permettant de configurer l’environnement node
   • Install dependencies : juste le script shell npm install pour installer toutes les dépendances du projet
   • Build Project : encore un script shell qui va builder le projet (le script est défini dans le package.json du projet et correspond à la commande de build de votre générateur de site statique).
   • Sync Files : une github action qui va déposer le répertoire désigné sur notre serveur FTP en utilisant les secrets définis précédemment dans github

C’est tout ! Désormais à chaque fois que du code sera poussé ou mergé sur notre branche principale, GitHub Actions va builder notre code et le déposer sur notre serveur !

Bonus : un environnement develop, par ce qu’on n’est pas des bêtes !

Si on s’enflamme, on pourrait très bien avoir envie de déployer dans un environnement de développement à chaque fois que l’on pousse sur une certaine branche…
Dans mon cas, je voudrais pouvoir pousser mon code dans une branche develop, vérifier que tout va bien dans un environnement de développement, avant de merger dans la branche main et de déployer en production.

Pour cela, il me suffit de créer un sous-domaine https://develop.votresite.fr/ lié à un dossier develop sur le serveur et de créer un deuxième fichier yaml develop.yml avec le code suivant :

name: Develop Deploy
on:
  push:
    branches:
      - "develop"
  workflow_dispatch:
jobs:
  web-deploy-on-develop:
    name: Deploy on develop
    runs-on: ubuntu-latest
    steps:
      - name: Get latest code
        uses: actions/checkout@v4
        with:
          ref: "develop"

      - name: Use Node.js 22
        uses: actions/setup-node@v4
        with:
          node-version: "22"

      - name: 📥 Install dependencies
        run: npm install -f

      - name: 🔨 Build Project
        run: npm run build

      - name: 📂 Sync files
        uses: SamKirkland/FTP-Deploy-Action@v4.3.5
        with:
          server: ${{ secrets.FTP_HOST }}
          username: ${{ secrets.FTP_USERNAME }}
          password: ${{ secrets.FTP_PASSWORD }}
          local-dir: ./public/
          server-dir: ./develop/

Ce fichier est quasiment identique au premier : il faut simplement changer le dossier de destination et modifier les noms du workflow, du job et de la branche impliquée.
Sinon vous aviez remarqué que j’aime bien les schémas ?