Double déploiement avec GitHub Actions

Ce rapport technique présente la conception et la mise en œuvre d'un pipeline CI/CD (Intégration Continue et Déploiement Continu) automatisé et centralisé via GitHub Actions.

L’objectif principal est d'orchestrer un double déploiement séquentiel et sans conflit d'une application web frontend vers deux environnements de production distincts : Vercel et GitHub Pages.

Ce que vous trouverez dans ce document :

Analyse comparative : Un tableau détaillé mettant en opposition les caractéristiques, performances et cas d'usage de GitHub Pages et de Vercel.

Architecture de pipeline : L'explication pas à pas des étapes du workflow (Checkout, Setup Node.js, gestion du cache npm, et builds différenciés).

Code source réutilisable : Le script complet du fichier de configuration deploy.yml commenté.

Gestion des erreurs (Troubleshooting) : Un retour d'expérience concret détaillant les 4 erreurs majeures rencontrées (erreurs de permissions 403, conflits de déploiement natif Vercel, configurations $git invalides) et les solutions techniques appliquées pour les résoudre.

Un guide pratique indispensable pour les développeurs, étudiants et ingénieurs DevOps souhaitant fiabiliser leur chaîne de livraison logicielle et maîtriser l'automatisation Cloud.

Transcript

1. RAPPORT TECHNIQUE ▷ Pipeline CI/CD Déploiement automatisé sur Vercel & GitHub Pages Auteur Beautero KENNE Encadrant Dr. ZEKENG NDANDJI Maxime Domaine DevOps / CI/CD Ce document est produit dans le cadre d’un apprentissage DevOps supervisé. Reproduction autorisée à des fins pédagogiques.
2. Table des matières 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Contexte du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Objectifs du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3 Enjeux DevOps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2 Présentation des plateformes . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1 GitHub Pages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1.1 Qu’est-ce que GitHub Pages ? . . . . . . . . . . . . . . . . . . . 5 2.1.2 Fonctionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1.3 Avantages et limitations . . . . . . . . . . . . . . . . . . . . . . 6 2.1.4 Cas d’usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2 Vercel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2.1 Qu’est-ce que Vercel ? . . . . . . . . . . . . . . . . . . . . . . . 6 2.2.2 Fonctionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2.3 Avantages et limitations . . . . . . . . . . . . . . . . . . . . . . 7 2.3 Tableau comparatif des plateformes . . . . . . . . . . . . . . . . . . . . 8 2.4 Pourquoi déployer sur les deux ? . . . . . . . . . . . . . . . . . . . . . 8 3 Gestion du déploiement automatique Vercel . . . . . . . . . . . . . . 9 3.1 Le mécanisme natif d’intégration GitHub . . . . . . . . . . . . . . . . . 9 3.2 Le problème : double déploiement . . . . . . . . . . . . . . . . . . . . . 10 3.3 Solutions pour désactiver le déploiement automatique . . . . . . . . . . 10 3.3.1 Méthode 1 — Via vercel.json (recommandée) . . . . . . . . . 11 3.3.2 Méthode 2 — Via l’interface Vercel (Ignored Build Step) . . . . 11 3.3.3 Méthode 3 — Déconnecter l’intégration Git . . . . . . . . . . . 12 3.4 Tableau comparatif des méthodes . . . . . . . . . . . . . . . . . . . . . 13 3.5 Notre approche : vercel.json + GitHub Actions . . . . . . . . . . . . 13 4 Architecture du pipeline CI/CD . . . . . . . . . . . . . . . . . . . . . . 15 4.1 Choix technologiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.2 Structure du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.3 Configuration des secrets GitHub . . . . . . . . . . . . . . . . . . . . . 16 4.4 Le pipeline complet — deploy.yml . . . . . . . . . . . . . . . . . . . . 16 4.4.1 Explication des étapes clés . . . . . . . . . . . . . . . . . . . . . 18 5 Déploiement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 5.1 Processus réel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 1
3. 5.2 Difficultés rencontrées et solutions apportées . . . . . . . . . . . . . . . 20 6 Résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 6.1 Liens des déploiements . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 6.2 Badge de statut CI/CD . . . . . . . . . . . . . . . . . . . . . . . . . . 22 7 Analyse & Retour d’expérience . . . . . . . . . . . . . . . . . . . . . . . 23 7.1 Ce qui a bien fonctionné . . . . . . . . . . . . . . . . . . . . . . . . . . 23 7.2 Axes d’amélioration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 7.3 Bonnes pratiques retenues . . . . . . . . . . . . . . . . . . . . . . . . . 23 8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 8.1 Résumé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 8.2 Apports pour l’apprentissage DevOps . . . . . . . . . . . . . . . . . . . 25 A Glossaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 B Ressources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 2
4. 1 Introduction 1.1 Contexte du projet Dans le cadre de mon apprentissage des pratiques DevOps modernes, j’ai été man- daté par un expert pour concevoir et implémenter un pipeline CI/CD (Continuous Integration / Continuous Deployment) capable de déployer automatiquement une ap- plication web frontend sur deux environnements de production distincts : Vercel et GitHub Pages. Cette mission constitue une application concrète des concepts fondamentaux du De- vOps, notamment l’automatisation des processus, la réduction des interventions ma- nuelles et la mise en place d’une chaîne de livraison logicielle fiable et reproductible. Note Définition — CI/CD : L’intégration continue (CI) automatise la vérification du code à chaque modification. Le déploiement continu (CD) prolonge ce pro- cessus en livrant automatiquement les changements validés en production, sans intervention humaine. 1.2 Objectifs du projet Cette mission poursuit quatre objectifs principaux : 1. Automatiser l’intégralité du processus de build et de déploiement, en éliminant toute opération manuelle susceptible d’introduire des erreurs. 2. Déployer simultanément l’application sur Vercel et GitHub Pages depuis un pipeline unique et centralisé. 3. Contrôler le déclenchement des déploiements afin d’éviter les conflits entre l’intégration native de Vercel et notre orchestrateur GitHub Actions. 4. Documenter l’ensemble du processus de manière claire et reproductible, confor- mément aux standards de l’industrie. 1.3 Enjeux DevOps L’automatisation du déploiement répond à plusieurs enjeux critiques dans un contexte professionnel : 3
5. Pipeline CI/CD — Vercel & GitHub Pages CHAPITRE 1. INTRODUCTION • Fiabilité Éliminer les erreurs humaines inhérentes aux déploiements manuels. • Rapidité Réduire le temps entre un commit et la mise en production de quelques heures à quelques minutes. • Traçabilité Chaque déploiement est lié à un commit précis, avec un historique complet et consultable. • Reproductibilité Le même pipeline produit le même résultat, quel que soit l’environnement d’exécution. Figure 1.1: Le cycle DevOps 4
6. 2 Présentation des plateformes 2.1 GitHub Pages 2.1.1 Qu’est-ce que GitHub Pages ? GitHub Pages est un service d’hébergement statique gratuit, intégré nativement à GitHub. Il permet de publier directement le contenu d’un repository Git sous forme de site web accessible publiquement. 2.1.2 Fonctionnement GitHub Pages lit le contenu d’une branche dédiée, généralement nommée gh-pages, ou d’un dossier /docs sur la branche principale, et le publie automatiquement à une URL de la forme : https://username.github.io/nom-du-repo Figure 2.1: Configuration de GitHub page sans GitHub Action 5
7. Pipeline CI/CD — Vercel & GitHub Pages CHAPITRE 2. PRÉSENTATION DES PLATEFORMES 2.1.3 Avantages et limitations Avantages Limitations Gratuit, sans limite de trafic Sites statiques uniquement (pas de SSR) Intégré nativement à GitHub Domaine en .github.io par défaut HTTPS automatique Pas de variables d’environnement ser- veur Idéal pour portfolios et docs Personnalisation limitée des headers HTTP 2.1.4 Cas d’usage GitHub Pages est particulièrement adapté pour héberger : portfolios personnels, documentations de projets open-source, pages de présentation de librairies, et sites vitrine statiques. 2.2 Vercel 2.2.1 Qu’est-ce que Vercel ? Vercel est une plateforme cloud de déploiement frontend conçue pour les applications modernes. Elle offre une infrastructure mondiale (CDN) optimisée pour les frameworks JavaScript tels que React, Next.js, Vue, Angular, Nuxt et SvelteKit. 2.2.2 Fonctionnement Lorsqu’un projet est lié à un repository GitHub, Vercel installe une GitHub App qui surveille les événements du repository. À chaque push, Vercel détecte automatiquement le framework utilisé, exécute le build, et déploie le résultat sur son infrastructure CDN mondiale. git push Developer GitHub Repository GitHub App Vercel Build Engine CDN Mondial webhook deploy mon-projet.vercel.app Figure 2.2: Flux de déploiement automatique Vercel via l’intégration GitHub 6
8. Pipeline CI/CD — Vercel & GitHub Pages CHAPITRE 2. PRÉSENTATION DES PLATEFORMES Figure 2.3: Dashboard Vercel montrant un déploiement réussi (statut ”Ready”) avec l’URL générée visible. 2.2.3 Avantages et limitations Avantages Limitations CDN mondial ultra-rapide Fonctionnalités team limitées (tier gra- tuit) HTTPS et domaines personnalisés Build minutes limitées en free tier Preview par Pull Request Logs limités en tier gratuit Support SSR / serverless Certaines configs nécessitent un abon- nement Analytics intégrés Lock-in partiel sur l’écosystème Vercel 7
9. Pipeline CI/CD — Vercel & GitHub Pages CHAPITRE 2. PRÉSENTATION DES PLATEFORMES 2.3 Tableau comparatif des plateformes Critère GitHub Pages Vercel Hébergement Statique uniquement Statique + SSR + Serverless Domaine gratuit username.github.io projet.vercel.app CI/CD intégré Via GitHub Actions Natif + GitHub Actions Performance Bonne Excellente (Edge Network) Previews PR Non Oui (automatique) Gratuit Oui (illimité) Oui (avec limites) Cas d’usage Portfolios, docs Apps React/Next.js, SaaS 2.4 Pourquoi déployer sur les deux ? Dans ce projet, le déploiement sur les deux plateformes n’est pas un doublon mais une démarche pédagogique et technique délibérée : • Démontrer la flexibilité du pipeline : un seul workflow orchestre deux cibles radicalement différentes. • Comparer les environnements en conditions réelles : performances, temps de build, URLs générées. • Valider la robustesse de l’automatisation : si l’un des déploiements échoue, l’autre reste disponible. • Acquérir une maîtrise des deux écosystèmes, très présents dans l’industrie. 8
10. 3 Gestion du déploiement automatique Ver- cel 3.1 Le mécanisme natif d’intégration GitHub Par défaut, lorsqu’un projet Vercel est connecté à un repository GitHub, Vercel ins- talle une GitHub App sur ce repository. Cette application écoute en permanence les événements Git via un système de webhooks. Note Un webhook est une méthode permettant à une application d’envoyer au- tomatiquement des données en temps réel à une autre application dès qu’un événement précis se produit Séquence de déclenchement native : git push origin main GitHub reçoit le push Webhook → GitHub App Vercel npm install && npm run build Déploiement ✓ mon-projet.vercel.app 9
11. Pipeline CI/CD — Vercel & GitHub Pages CHAPITRE 3. GESTION DU DÉPLOIEMENT AUTOMATIQUE VERCEL Figure 3.1: GitHub App Vercel installée sur votre repository 3.2 Le problème : double déploiement Dans notre contexte, c’est GitHub Actions qui doit orchestrer intégralement le déploiement. Laisser Vercel en mode automatique génère un conflit critique : git push main Vercel auto-déploie (non contrôlé) GitHub Actions (notre pipeline) Deploy Vercel ✓ Deploy GitHub Pages ✓ × Attention Sans désactivation, deux déploiements Vercel s’exécutent en parallèle à chaque push, consommant le quota inutilement et rendant le pipeline imprévisible. 3.3 Solutions pour désactiver le déploiement automatique 10
12. Pipeline CI/CD — Vercel & GitHub Pages CHAPITRE 3. GESTION DU DÉPLOIEMENT AUTOMATIQUE VERCEL 3.3.1 Méthode 1 — Via vercel.json (recommandée) La méthode la plus propre consiste à ajouter un fichier vercel.json à la racine du projet. Ce fichier est versionné dans Git, ce qui garantit que la configuration est reproductible sur toutes les machines. vercel.json — Désactiver tous les déploiements automatiques { "$schema": "https://openapi.vercel.sh/vercel.json", "git": { "deploymentEnabled": false } } Il est également possible de cibler seulement certaines branches : vercel.json — Désactivation sélective par branche { "$schema": "https://openapi.vercel.sh/vercel.json", "git": { "deploymentEnabled": { "main": false, "develop": false, "internal -*": false } } } Figure 3.2: Désactivation du déploiement automatique de vercel via le fichier vercel.json 3.3.2 Méthode 2 — Via l’interface Vercel (Ignored Build Step) Dans le dashboard Vercel, naviguer vers Settings → Build & Deployment → Ignored Build Step et entrer la commande suivante : 11
13. Pipeline CI/CD — Vercel & GitHub Pages CHAPITRE 3. GESTION DU DÉPLOIEMENT AUTOMATIQUE VERCEL Ignored Build Step — Commande à entrer dans Vercel exit 1 Cette commande retourne toujours un code d’erreur, ce qui signale à Vercel d’annuler le build automatique à chaque tentative. Figure 3.3: Exemple de configuration avec une commande exit 1 dans Ignored Build Step, utilisée pour forcer l’annulation automatique du build. Cas où vous choisissez explicitement l’option “Don’t build anything” dans Vercel: Cette option indique à Vercel de ne lancer aucun processus de build lors des déploiements automatiques. Ainsi, le projet est déployé tel quel, sans exécution de commandes supplémentaires, ce qui évite les erreurs et empêche l’annulation du build par défaut. Figure 3.4: Exemple de configuration avec l’option Don’t build anything dans Ignored Build Step, qui désactive complètement le processus de build. 3.3.3 Méthode 3 — Déconnecter l’intégration Git La méthode la plus radicale consiste à retirer complètement l’intégration GitHub dans Settings → Git → Disconnect. Attention Cette approche supprime également les previews automatiques sur les Pull Re- quests. À réserver aux projets où seul le pipeline CI/CD doit déclencher les déploiements. 12
14. Pipeline CI/CD — Vercel & GitHub Pages CHAPITRE 3. GESTION DU DÉPLOIEMENT AUTOMATIQUE VERCEL Figure 3.5: Retirer complètement l’intégration GitHub 3.4 Tableau comparatif des méthodes Méthode Où configurer Avantage Inconvénient vercel.json Code source (Git) Versionné, por- table Nécessite un com- mit Ignored Build Step Dashboard Vercel Sans modifier le code Config hors du repo Déconnexion Git Dashboard Vercel Contrôle total Perd les PR pre- views 3.5 Notre approche : vercel.json + GitHub Actions Dans ce projet, nous optons pour la Méthode 1 (vercel.json). Le flux final maîtrisé est le suivant : git push main Vercel GitHub App Bloqué par vercel.json × GitHub Actions Déclenché ✓ Build Deploy Vercel ✓ Deploy GitHub Pages ✓ 13
15. Pipeline CI/CD — Vercel & GitHub Pages CHAPITRE 3. GESTION DU DÉPLOIEMENT AUTOMATIQUE VERCEL Bonne pratique Le contrôle du déclenchement des déploiements est un aspect critique de tout pipeline CI/CD mature. Déléguer ce déclenchement à un seul orchestrateur — ici GitHub Actions — garantit la traçabilité, évite les race conditions et assure la reproductibilité des builds. 14
16. 4 Architecture du pipeline CI/CD 4.1 Choix technologiques Outil Rôle Justification GitHub Actions Orchestration CI/CD Natif GitHub, gratuit, YAML Node.js 18 LTS Environnement de build Standard écosystème frontend npm ci Installation dépen- dances Builds reproductibles en CI Vercel CLI via Action Déploiement Vercel Contrôle programma- tique total peaceiris/actions-gh-pages Déploiement GitHub Pages Action officielle, fiable Note Pourquoi npm ci et non npm install ? La commande npm ci lit package-lock.json et installe les versions exactes des dépendances, garan- tissant un build identique quelle que soit la machine. npm install peut mettre à jour les versions et provoquer des comportements non déterministes en CI. 4.2 Structure du projet Arborescence du projet mon-projet/ src/ # Code source de l'application dist/ # Dossier de build (output) public/ # Fichiers statiques .github/ workflows/ deploy.yml # <-- LE FICHIER CLE DU PIPELINE vercel.json # Configuration Vercel (desactive 15
17. Pipeline CI/CD — Vercel & GitHub Pages CHAPITRE 4. ARCHITECTURE DU PIPELINE CI/CD auto-deploy) package.json README.md 4.3 Configuration des secrets GitHub Les credentials sensibles (tokens API) ne doivent jamais être écrits en clair dans le code source. GitHub offre un mécanisme de Secrets chiffrés, accessibles dans Settings → Secrets and variables → Actions. Les secrets à configurer pour ce projet : Nom du secret Description VERCEL_TOKEN Token d’API Vercel (généré dans Account Set- tings → Tokens) VERCEL_ORG_ID Identifiant de l’organisation Vercel VERCEL_PROJECT_ID Identifiant unique du projet sur Vercel GITHUB_TOKEN Fourni automatiquement par GitHub Actions (pas à créer) Figure 4.1: Exemple de configuration des secrets GitHub dans montrant les clés nécessaires au déploiement (valeurs masquées pour des raisons de sécurité). 4.4 Le pipeline complet — deploy.yml .github/workflows/deploy.yml — Pipeline CI/CD complet 1 name: CI/CD -- Deploy to Vercel & GitHub Pages 2 3 # Declenchement : uniquement sur push vers main 4 on: 5 push: 6 branches: 16
18. Pipeline CI/CD — Vercel & GitHub Pages CHAPITRE 4. ARCHITECTURE DU PIPELINE CI/CD 7 - main 8 9 jobs: 10 build-and-deploy: 11 runs-on: ubuntu -latest 12 permissions: 13 contents: write 14 15 steps: 16 # Etape 1 : Recuperer le code source 17 - name: Checkout repository 18 uses: actions/checkout@v6 19 20 # Etape 2 : Configurer Node.js 24 LTS 21 - name: Setup Node.js 22 uses: actions/setup-node@v6 23 with: 24 node-version: '24' 25 cache: 'npm' 26 27 # Etape 3 : Installer les dependances (mode CI) 28 - name: Install dependencies 29 run: npm ci 30 31 # Etape 4a : Build pour Vercel (base "/") 32 - name: Build application 33 run: npm run build 34 35 # Etape 5 : Deployer sur Vercel 36 - name: Deploy to Vercel 37 uses: amondnet/vercel -action@v42 38 with: 39 vercel -token: ${{ secrets.VERCEL_TOKEN }} 40 vercel -org-id: ${{ secrets.VERCEL_ORG_ID }} 41 vercel -project -id: ${{ secrets.VERCEL_PROJECT_ID }} 42 vercel -args: '--prod' 43 44 # Etape 4b : Build pour GitHub Pages (base "/ devops -journey/") 45 - name: Build for GitHub Pages 46 run: npm run build:gh 47 17
19. Pipeline CI/CD — Vercel & GitHub Pages CHAPITRE 4. ARCHITECTURE DU PIPELINE CI/CD 48 # Etape 6 : Deployer sur GitHub Pages 49 - name: Deploy to GitHub Pages 50 uses: peaceiris/actions -gh-pages@v3 51 with: 52 github_token: ${{ secrets.GITHUB_TOKEN }} 53 publish_dir: ./dist 4.4.1 Explication des étapes clés Étape 1 — Checkout : L’action actions/checkout@v6 clone le repository dans l’environnement d’exécution du runner (machine virtuelle Ubuntu hébergée par Gi- tHub). Sans cette étape, aucun fichier source n’est disponible. Étape 3 — npm ci : Contrairement à npm install, cette commande garantit l’installation des versions exactes déclarées dans package-lock.json. Indispensable en environne- ment CI pour des builds déterministes. Étape 5 — Deploy Vercel : L’argument --prod indique à Vercel que ce déploiement est destiné à la production (et non à un environnement de preview). Le token d’API est injecté depuis les Secrets GitHub, jamais écrit en clair. Étape 6 — Deploy GitHub Pages : L’action peaceiris/actions-gh-pages@v3 pousse le contenu du dossier ./dist vers la branche gh-pages. Le GITHUB_TOKEN est automatiquement fourni par GitHub Actions. 18
20. 5 Déploiement 5.1 Processus réel Le déploiement se déclenche automatiquement à chaque git push sur la branche main. La séquence complète est la suivante : 1. git add . && git commit -m "feat: nouvelle fonctionnalité" 2. git push origin main 3. GitHub détecte le push et déclenche le workflow deploy.yml 4. L’onglet Actions du repository affiche l’exécution en temps réel 5. Les deux déploiements s’effectuent séquentiellement 6. Les URLs de production sont mises à jour Figure 5.1: GitHub montrant le workflow terminé avec succès (icône verte ✓). 19
21. Pipeline CI/CD — Vercel & GitHub Pages CHAPITRE 5. DÉPLOIEMENT Figure 5.2: Capture détaillée d’un job avec les étapes dépliées et les logs d’exécution visibles (montrant notamment les étapes build et deploy). 5.2 Difficultés rencontrées et solutions apportées # Difficulté Solution apportée 1 Fichier vercel.json invalide (pro- priété non supportée $git) Supprimer la clé $git et ne conser- ver que les propriétés valides (builds, routes, env, etc.) 2 Permissions insuffisantes pour pousser sur la branche gh-pages (erreur 403) Activer les permissions contents: write pour GITHUB_TOKEN ou utiliser un PAT avec scope repo 3 GitHub Pages ne se met pas à jour Activer GitHub Pages sur la branche gh-pages dans Settings → Pages 4 Double déploiement Vercel (natif + Actions) Ajouter vercel.json avec deploymentEnabled: false 20
22. 6 Résultats 6.1 Liens des déploiements Plateforme URL de production Statut Vercel https://devops-journey-five.vercel.app ✓ Live GitHub Pages https://beautero-ks.github.io/devops-journey/ ✓ Live Figure 6.1: Capture d’écran de l’application déployée sur Vercel, avec l’URL vercel.app visible dans la barre d’adresse du navigateur. 21
23. Pipeline CI/CD — Vercel & GitHub Pages CHAPITRE 6. RÉSULTATS Figure 6.2: Capture d’écran l’application déployée sur GitHub Pages, avec l’URL github.io visible dans la barre d’adresse du navigateur. Figure 6.3: Dashboard Vercel montrant l’historique des déploiements. 6.2 Badge de statut CI/CD Un badge de statut peut être ajouté au README.md du projet pour afficher en temps réel l’état du pipeline : README.md — Badge de statut CI/CD  Ce badge affiche automatiquement passing ou failing selon le résultat du dernier pipeline. 22
24. 7 Analyse & Retour d’expérience 7.1 Ce qui a bien fonctionné L’utilisation de GitHub Actions comme orchestrateur central s’est révélée particu- lièrement efficace, permettant une gestion unifiée des deux déploiements depuis un seul fichier de configuration YAML. La séparation claire des responsabilités — build d’un côté, déploiements de l’autre — a rendu le pipeline lisible et maintenable. La gestion des secrets via le mécanisme natif de GitHub s’est avérée simple et sécurisée. Aucun credential sensible n’apparaît dans le code source ou les logs d’exécution. 7.2 Axes d’amélioration • Ajouter des tests automatisés (unitaires et d’intégration) avant l’étape de build, afin de bloquer tout déploiement en cas de régression. • Mettre en place des notifications (Slack, email) en cas d’échec du pipeline, pour une réactivité optimale. • Introduire un environnement de staging — déployer d’abord sur un environ- nement de préproduction (ex: preview Vercel), valider, puis promouvoir en produc- tion. • Implémenter le cache npm (déjà amorcé avec cache: 'npm') et le cache des artifacts pour réduire le temps d’exécution du pipeline. 7.3 Bonnes pratiques retenues Bonne pratique • Ne jamais committer de secrets dans le code source — utiliser exclusi- vement les GitHub Secrets. • Utiliser npm ci (et non npm install) en environnement CI pour des builds reproductibles. • Versionner les actions utilisées (@v3) pour éviter les breaking changes non anticipés. • Nommer explicitement chaque étape du workflow pour faciliter le diag- nostic en cas d’erreur. 23
25. Pipeline CI/CD — Vercel & GitHub Pages CHAPITRE 7. ANALYSE & RETOUR D’EXPÉRIENCE • Désactiver le déploiement automatique natif de Vercel dès que GitHub Actions est en charge de l’orchestration. 24
26. 8 Conclusion 8.1 Résumé Ce projet a permis de concevoir et d’implémenter un pipeline CI/CD complet, depuis la réception d’un git push jusqu’au déploiement simultané de l’application sur Ver- cel et GitHub Pages. L’orchestration centralisée via GitHub Actions garantit un processus automatisé, traçable et reproductible. La gestion fine du déclenchement des déploiements Vercel — via le fichier vercel.json — constitue un point technique clé, illustrant l’importance de maîtriser chaque com- posant de la chaîne CI/CD plutôt que de s’en remettre aux comportements par défaut des outils. 8.2 Apports pour l’apprentissage DevOps Cette mission a consolidé plusieurs compétences fondamentales du parcours DevOps : • Comprendre le fonctionnement des webhooks et intégrations GitHub dans un contexte de déploiement. • Maîtriser la syntaxe YAML de GitHub Actions pour construire des workflows modulaires. • Appréhender l’importance de la sécurité des credentials dans un pipeline auto- matisé. • Identifier et résoudre des conflits entre outils (déploiement Vercel natif vs pipe- line CI/CD). • Adopter une culture de documentation rigoureuse, indispensable dans un envi- ronnement d’équipe. 25
27. A Glossaire CI/CD Continuous Integration / Continuous Deployment. Pratique consis- tant à automatiser les phases de test, build et déploiement du logiciel. Pipeline Enchaînement d’étapes automatisées transformant le code source en application déployée. Webhook Mécanisme permettant à un service d’envoyer automatiquement une notification HTTP à un autre service lors d’un événement. CDN Content Delivery Network. Réseau de serveurs distribués géographi- quement pour servir le contenu au plus près de l’utilisateur. Secret Credential sensible (token, mot de passe) stocké de manière chiffrée et injecté dans le pipeline sans apparaître dans les logs. Runner Machine virtuelle (souvent Ubuntu) fournie par GitHub pour exécuter les jobs d’un workflow GitHub Actions. Artifact Fichier ou ensemble de fichiers produits par une étape du pipeline (ex: le dossier dist après un build). SSR Server-Side Rendering. Rendu des pages web côté serveur, supporté par Vercel mais pas par GitHub Pages. 26
28. B Ressources • Documentation GitHub Actions : https://docs.github.com/en/actions • Documentation GitHub Pages : https://pages.github.com • Documentation Vercel : https://vercel.com/docs • Documentation GitHub Marketplace : https://github.com/marketplace/actions • Configuration Git Vercel : https://vercel.com/docs/project-configuration/ git-configuration • Action peaceiris/actions-gh-pages : https://github.com/peaceiris/actions-gh-pages • Action amondnet/vercel-action : https://github.com/amondnet/vercel-action 27