Configurer le déploiement automatisé

Apprends à mettre en place un déploiement CI/CD avec GitHub Actions, Docker et un runner auto-hébergé pour ton projet React Router 7.

5 min read
Déverrouillez votre potentiel

avec React Router 7

Vous en avez marre de...

❌ perdre du temps à chercher des informations éparpillées
❌ ne pas avoir de retour sur votre progression
Assistant IA spécialisé

Posez vos questions 24/7 à notre IA experte en React Router 7

Quiz interactifs

Validez vos acquis avec des quiz personnalisés et un feedback instantané

9 modules
53 leçons
Accès à vie
460.75

Objectif : déclencher un déploiement depuis GitHub

Dans la vidéo tu as :

  • créé un runner auto-hébergé sur ton VPS ;
  • poussé l’app Dockerisée sur Docker Hub ;
  • configuré trois fichiers docker-compose (dev, staging, prod) ;
  • écrit un workflow GitHub Actions qui
    1. build l’image,
    2. vérifie le type Script,
    3. déploie automatiquement en fonction de la branche.

Nous allons revoir chaque étape et comprendre la logique pour que tu puisses l’adapter à n’importe quel projet React Router 7.


1. Préparer le runner auto-hébergé

Un runner est juste un petit agent qui attend les ordres de GitHub ; dès qu’un workflow contient runs-on: self-hosted, c’est lui qui exécute les commandes.

1.1 Installer le binaire GitHub Runner

Terminal
1
# Sur ton VPS, connecté avec l'utilisateur créé précédemment
2
mkdir -p ~/deployments/react-router-7 && cd ~/deployments/react-router-7
3
curl -o actions-runner-linux-x64-2.316.0.tar.gz \
4
-L https://github.com/actions/runner/releases/download/v2.316.0/actions-runner-linux-x64-2.316.0.tar.gz
5
tar xzf actions-runner-linux-x64-2.316.0.tar.gz
6
./config.sh # ↩️ colle ici le token fourni par GitHub

1.2 Lancer le service en tâche de fond

Terminal
1
sudo ./svc.sh install # installe le service systemd
2
sudo ./svc.sh start # démarre le runner
3
sudo ./svc.sh status # doit afficher Active: running

Le statut passe en idle dans l’onglet Settings → Actions → Runners de ton repo : GitHub est désormais capable de piloter ton serveur.


2. Factoriser le build Docker

Plutôt que de copier/coller la même liste de steps dans tous tes workflows, encapsule la partie “build + push” dans un workflow réutilisable.

.github/workflows/build.yml
1
name: 🐳 Build And Push Docker Image
2
3
on:
4
workflow_call: # 🤝 appelé depuis un autre fichier
5
inputs:
6
tag:
7
type: string
8
9
jobs:
10
build:
11
runs-on: ubuntu-latest
12
steps:
13
- uses: actions/checkout@v4
14
- uses: docker/login-action@v2
15
with:
16
username: ${{ secrets.DOCKERHUB_USERNAME }}
17
password: ${{ secrets.DOCKERHUB_TOKEN }}
18
19
- uses: docker/setup-buildx-action@v2 # build multi-arch
20
- name: Build ${{ inputs.tag }}
21
uses: docker/build-push-action@v3
22
with:
23
context: .
24
push: true
25
tags: algomax/react-router-7:${{ inputs.tag }}

3. La CI : type-check + build

.github/workflows/ci.yml
1
name: Docker Image CI
2
3
on:
4
push:
5
branches: ["main", "dev"]
6
pull_request:
7
branches: ["main", "dev"]
8
9
jobs:
10
build:
11
name: 🐳 build
12
uses: ./.github/workflows/build.yml
13
with:
14
tag: ${{ github.ref == 'refs/heads/main' && 'production' || 'latest' }}
15
secrets: inherit # ↩️ transmet DOCKERHUB_* au sous-workflow
16
17
typecheck:
18
runs-on: ubuntu-latest
19
steps:
20
- uses: actions/checkout@v4
21
- name: Install deps
22
run: npm ci
23
- name: TypeScript strict
24
run: npm run typecheck

4. Déploiement automatisé sur le VPS

.github/workflows/ci.yml {29-67}
1
deploy:
2
name: 🚀 Deploy
3
runs-on: [self-hosted] # ⬅️ notre runner VPS
4
needs: [build, typecheck]
5
if: ${{ github.event_name == 'push' }}
6
env: # variables communes
7
SMTP_USER: ${{ secrets.SMTP_USER }}
8
SMTP_PASSWORD: ${{ secrets.SMTP_PASSWORD }}
9
SMTP_PORT: ${{ secrets.SMTP_PORT }}
10
SMTP_SENDER: ${{ secrets.SMTP_SENDER }}
11
SMTP_HOST: ${{ secrets.SMTP_HOST }}
12
13
steps:
14
- uses: actions/checkout@v4
15
- uses: docker/login-action@v2
16
with:
17
username: ${{ secrets.DOCKERHUB_USERNAME }}
18
password: ${{ secrets.DOCKERHUB_TOKEN }}
19
20
- name: 🏗️ Pull & run – staging
21
if: github.ref == 'refs/heads/dev'
22
env:
23
FRONTEND_URL: ${{ secrets.FRONTEND_URL_STAGING }}
24
DATABASE_URL: ${{ secrets.DATABASE_URL_STAGING }}
25
run: |
26
docker pull algomax/react-router-7:latest
27
docker compose -f docker-compose.staging.yml up -d
28
docker system prune --all --volumes --force
29
30
- name: 🏗️ Pull & run – production
31
if: github.ref == 'refs/heads/main'
32
env:
33
FRONTEND_URL: ${{ secrets.FRONTEND_URL }}
34
DATABASE_URL: ${{ secrets.DATABASE_URL }}
35
run: |
36
docker pull algomax/react-router-7:production
37
docker compose -f docker-compose.prod.yml up -d
38
docker system prune --all --volumes --force
  • Deux environnements : – dev pousse sur l’image latest, exposée port 3010; – main pousse sur production, exposée port 3000.
  • docker system prune garde le VPS propre (images et volumes obsolètes).

5. Les fichiers docker-compose

docker-compose.prod.yml
1
services:
2
react_router_production:
3
image: algomax/react-router-7:production
4
container_name: react_router_production
5
env_file: .env.production # Secrets montés à part
6
restart: always
7
ports:
8
- "3000:3000"
docker-compose.staging.yml
1
services:
2
react_router_staging:
3
image: algomax/react-router-7:latest
4
container_name: react_router_staging
5
env_file: .env.staging
6
restart: always
7
ports:
8
- "3010:3000"

6. Secrets & variables GitHub

  1. Settings → Secrets and variables → Actions
  2. Ajoute : DOCKERHUB_USERNAME, DOCKERHUB_TOKEN, SMTP_*, FRONTEND_URL, DATABASE_URL, etc.
  3. Les secrets sont injectés dans le workflow via ${{ secrets.MA_VARIABLE }}.

7. Cycle complet d’une mise en production

1
flowchart LR
2
dev[Dev push] -->|branch dev| ci(Build+Type) --> VPSStaging
3
main[Merge → main] -->|branch main| ci2(Build+Type) --> VPSProd
  1. Push sur dev ➜ image latest, déploiement staging (port 3010).
  2. Merge vers main ➜ image production, déploiement prod (port 3000).
  3. Les deux conteneurs co-habitent, redémarrables à la commande :
Terminal
1
docker restart react_router_staging
2
docker restart react_router_production

8. Tester en local : le mode développeur

Terminal
1
# Porte 3000, rebuild sur chaque changement
2
docker compose -f docker-compose.dev.yml up --build

La version dev utilise le Dockerfile pour conserver le hot-reload tandis que staging/prod tirent l’image déjà buildée.


9. Nommage et bonne pratique Docker

  • Nom de conteneur explicite (react_router_staging) => auto-complétion docker stop rea<Tab>.
  • Redémarrage avec docker restart, pas besoin de rejouer la CI.
  • Prune régulier des images obsolètes :
Terminal
1
docker system prune --all --volumes

10. Prochaine étape : le reverse proxy HTTPS

Le site répond déjà sur :3000 via l’adresse IP, mais un vrai domaine exigera :

  1. un enregistrement A vers l’IP VPS ;
  2. Caddy (ou Nginx) pour gérer TLS et rediriger https://rr7.algomax.frhttp://localhost:3000.

Nous détaillons ça dans la leçon suivante.

Premium
Quiz interactif
Testez vos connaissances et validez votre compréhension du module avec notre quiz interactif.
1

Comprendre les concepts fondamentaux

Quelle est la principale différence entre les composants client et serveur dans React ?

Les composants client s'exécutent uniquement dans le navigateur
Les composants serveur peuvent utiliser useState
Les composants client sont plus rapides
Il n'y a aucune différence significative
2

Optimisation des performances

Quelle technique est recommandée pour éviter les rendus inutiles dans React ?

Utiliser React.memo pour les composants fonctionnels
Ajouter plus d'états locaux
Éviter d'utiliser les props
Toujours utiliser les class components
3

Architecture des données

Quel hook permet de gérer les effets de bord dans un composant React ?

useEffect
useState
useMemo
useContext
4

Gestion des erreurs

Comment implémenter la gestion des erreurs pour les requêtes API dans React ?

Utiliser try/catch avec async/await
Ignorer les erreurs
Toujours afficher un message d'erreur
Rediriger l'utilisateur
5

Déploiement et CI/CD

Quelle est la meilleure pratique pour déployer une application React en production ?

Utiliser un service CI/CD comme GitHub Actions
Copier les fichiers manuellement via FTP
Envoyer le code source complet
Ne jamais mettre à jour l'application

Débloquez ce quiz et tous les autres contenus premium en achetant ce cours