Formation : CI/CD avec GitHub Actions

• Développeurs web (Node.js, PHP, Python) maîtrisant Git et GitHub et souhaitant automatiser leurs tests et leurs déploiements.
• Développeurs ayant suivi la formation Git et GitHub : gestion de versions pour débutants ou disposant d'une expérience équivalente avec les branches, les pull requests et les dépôts distants.
• Équipes de développement souhaitant standardiser leur workflow de livraison et supprimer les déploiements manuels.
• Freelances cherchant à livrer des projets plus fiables grâce à des pipelines d'intégration et de déploiement continus.
• Développeurs ayant suivi la formation Docker pour développeurs web et souhaitant automatiser le build et le push de leurs images.

• Comprendre les concepts CI/CD : intégration continue, livraison continue, déploiement continu
• Maîtriser la syntaxe YAML des workflows GitHub Actions : events, jobs, steps, runners
• Automatiser les tests unitaires et d'intégration sur chaque push ou pull request
• Gérer les secrets et les variables d'environnement de façon sécurisée dans les workflows
• Construire et publier des images Docker depuis un pipeline GitHub Actions
• Déployer automatiquement sur un VPS via SSH ou sur une plateforme cloud (Render, Railway)
• Utiliser les environnements GitHub pour gérer les déploiements staging et production
• Optimiser les workflows : cache des dépendances, jobs parallèles, conditions et matrices

• Maîtrise de Git et GitHub : commits, branches, merges, pull requests, dépôts distants. La formation Git et GitHub : gestion de versions pour débutants est recommandée ou une expérience équivalente.
• Avoir un projet web fonctionnel dans au moins un langage (Node.js, PHP ou Python) avec une suite de tests basique existante ou en cours de création.
• Notions de base sur le terminal Linux et les variables d'environnement.
• Notions de base sur le format YAML : indentation, listes, dictionnaires.
• La formation Docker pour développeurs web est un plus mais n'est pas obligatoire — le Module 5 sur Docker dans les pipelines est accessible sans expérience Docker préalable.

• L'intégration continue : détecter les régressions au plus tôt sur chaque modification du code
• La livraison continue : maintenir le code toujours déployable, automatiser jusqu'au staging
• Le déploiement continu : aller jusqu'en production sans intervention humaine
• Ce que la CI/CD change concrètement : fin des conflits de merge douloureux, des déploiements manuels à risque
• L'écosystème CI/CD : GitHub Actions, GitLab CI, CircleCI, Jenkins

• Les composants clés : workflow, event, job, step, action, runner
• Les runners : GitHub-hosted (ubuntu, windows, macos) vs self-hosted
• Le répertoire .github/workflows/ : convention de nommage, un fichier par workflow
• La syntaxe YAML : indentation stricte, types de valeurs, chaînes multilignes
• L'interface GitHub Actions : onglet Actions, visualisation du pipeline, logs en temps réel
• Les minutes gratuites : quotas par plan, runners payants, optimiser la consommation

• push : déclencher sur des branches spécifiques, exclure des chemins avec paths-ignore
• pull_request : déclencher sur l'ouverture, la mise à jour, la synchronisation d'une PR
• workflow_dispatch : déclencher manuellement depuis l'interface avec des inputs
• schedule : déclenchement planifié avec la syntaxe cron
• release : déclencher sur la publication d'une release GitHub
• Combiner plusieurs événements avec la liste on

• Déclarer un job : runs-on, steps, needs pour les dépendances entre jobs
• Les actions officielles : actions/checkout, actions/setup-node, actions/setup-python, actions/setup-php
• Les commandes shell dans les steps : run single-line vs multiline avec |
• Les contextes GitHub Actions : github, env, steps, runner
• Passer des données entre steps : outputs, variables d'environnement dans $GITHUB_ENV
• Les conditions : if sur un job ou un step, success(), failure(), github.ref

• Configurer l'environnement Node.js : actions/setup-node avec la version cible
• Installer les dépendances avec npm ci pour la reproductibilité
• Lancer les tests : npm test avec Jest ou Vitest
• Linter le code : ESLint dans le pipeline
• Vérifier le formatage : Prettier en mode --check
• Publier les résultats de tests : rapport JUnit avec actions/upload-artifact

• PHP : configurer shivammathur/setup-php, installer avec Composer, lancer PHPUnit, analyser avec PHPStan
• Python : configurer actions/setup-python, installer avec pip, lancer pytest, linter avec flake8 ou ruff
• Gérer les dépendances de test : base de données de test, variables d'environnement
• Services GitHub Actions : lancer un conteneur PostgreSQL ou MySQL comme service annexe

• Cache des dépendances : actions/cache pour node_modules, pip, Composer
• La stratégie matrix : tester sur plusieurs versions de Node.js ou PHP en parallèle
• Jobs parallèles : lint, tests unitaires et tests d'intégration en simultané
• Fail-fast : arrêter tous les jobs de la matrice dès qu'un échoue
• Artifacts : uploader les rapports de couverture, les captures d'écran de tests E2E

• Pourquoi ne jamais stocker de secrets dans le code ou dans les logs de workflow
• Les secrets GitHub : repository secrets, organisation secrets, environment secrets
• Déclarer et utiliser un secret dans un workflow : ${{ secrets.MON_SECRET }}
• Les variables GitHub Actions (vars) : pour les valeurs non sensibles, réutilisables entre workflows
• Les secrets masqués dans les logs : comportement par défaut, précautions supplémentaires

• Les environnements GitHub : créer "staging" et "production" dans les paramètres du dépôt
• Les protection rules : approbation manuelle requise avant un déploiement en production
• Les secrets par environnement : des credentials différents pour staging et production
• Référencer un environnement dans un job : environment: production
• L'historique de déploiement : visualiser qui a déployé quoi, quand, avec quel statut

• L'action docker/build-push-action : la référence pour les pipelines Docker
• S'authentifier sur un registre depuis le workflow : Docker Hub, GitHub Container Registry
• Construire et tagger l'image avec le SHA du commit et le tag latest
• Le cache de layers Docker dans GitHub Actions : cache-from et cache-to
• Le multi-platform build : produire des images linux/amd64 et linux/arm64

• Pourquoi scanner : CVE dans les images de base, dépendances avec des failles connues
• Scanner les dépendances npm/pip/composer : npm audit, pip-audit, Dependabot
• Scanner l'image Docker avec Trivy : intégration dans le pipeline, seuil de sévérité, rapport SARIF
• Publier le rapport de sécurité dans l'onglet "Security" de GitHub
• Dependabot : automatiser les mises à jour de dépendances

• Générer une paire de clés SSH dédiée au déploiement
• Stocker la clé privée dans les secrets GitHub, installer la clé publique sur le VPS
• Se connecter au VPS depuis le workflow avec appleboy/ssh-action
• Commandes de déploiement : docker compose pull + docker compose up -d
• Vérifier le déploiement : healthcheck HTTP après le redémarrage des conteneurs
• Rollback manuel : revenir à l'image précédente en cas d'échec du healthcheck

• Render : déploiement depuis une image Docker via l'API Render
• Railway : déploiement depuis le dépôt GitHub ou depuis une image
• Les variables d'environnement sur ces plateformes : synchroniser avec les secrets GitHub Actions
• Stratégie blue-green simplifiée sur Render : zero-downtime deployment
• Comparer les approches : VPS vs plateforme cloud

• Les actions composites : factoriser une séquence de steps récurrente dans une action réutilisable locale
• Créer une action composite dans .github/actions/ : action.yaml, inputs, outputs
• Les reusable workflows : partager un workflow entier entre plusieurs dépôts avec workflow_call
• Passer des inputs et des secrets à un workflow réutilisable
• Les actions du Marketplace : évaluer une action tierce, étoiles, mainteneur, code source, permissions
• Épingler les actions à un commit SHA pour prévenir les supply chain attacks

• Les branch protection rules sur main : bloquer le push direct, exiger des PR
• Les required status checks : empêcher le merge d'une PR si le workflow CI est rouge
• Les required reviews : combiner validation humaine et validation automatique
• La règle "dismiss stale reviews" : invalider les approbations après un nouveau commit
• CODEOWNERS : assigner automatiquement des reviewers selon les fichiers modifiés

• Générer un rapport de couverture : Istanbul/c8 pour Node.js, coverage.py pour Python, Xdebug pour PHP
• Publier la couverture dans les commentaires de PR avec actions/github-script
• Intégrer Codecov ou Coveralls : badge de couverture dans le README, historique des tendances
• CodeQL : analyse statique de sécurité gratuite pour les dépôts publics
• Afficher les annotations de lint directement dans les diffs de PR

• Activer le debug logging : ACTIONS_RUNNER_DEBUG et ACTIONS_STEP_DEBUG
• Re-run un job en mode debug depuis l'interface GitHub
• Tester localement avec act : simuler GitHub Actions sur sa machine avant de pousser
• Mesurer la durée des jobs : identifier les étapes lentes, optimiser en priorité
• Les concurrency groups : annuler un run en cours quand un nouveau est déclenché
• Recevoir des notifications sur l'état des workflows : email, Slack via webhook

• Choisir le projet : apporter une application existante ou utiliser un projet fourni
• Cartographier le pipeline cible : événements, jobs, étapes, environnements
• Identifier les secrets nécessaires et leur portée
• Choisir la cible de déploiement : VPS via SSH ou plateforme cloud
• Estimer la durée du pipeline et identifier les optimisations à prioriser

• Étape 1 : workflow CI, tests, lint, couverture, rapport sur la PR
• Étape 2 : workflow CD, build image Docker, push registre, déploiement staging automatique
• Étape 3 : protection de la branche main et gate de production avec approbation
• Étape 4 : optimisation, cache, jobs parallèles, concurrency group

• Écrire des workflows GitHub Actions structurés et maintenables en YAML
• Automatiser les tests, le lint et la couverture de code sur chaque pull request
• Gérer les secrets et les variables d'environnement de façon sécurisée par environnement
• Construire et publier des images Docker depuis un pipeline avec cache de layers
• Déployer automatiquement sur un VPS ou une plateforme cloud avec gate de production
• Optimiser un pipeline : cache des dépendances, jobs parallèles, actions composites réutilisables

• En cours de formation : pipelines construits et testés en direct à chaque module
• En fin de formation : pipeline CI/CD complet sur un projet réel avec déploiement automatique
• Questionnaire d'auto-évaluation des acquis en fin de parcours

• Workflows GitHub Actions fonctionnels avec déclencheurs, jobs et steps correctement structurés
• Cache des dépendances actif et jobs parallèles réduisant le temps de pipeline
• Secrets et variables d'environnement correctement isolés par environnement GitHub
• Pipeline CI bloquant le merge d'une PR en cas d'échec des tests ou du lint
• Déploiement automatique fonctionnel sur staging avec gate de production opérationnel
• Actions composites ou reusable workflows réduisant la duplication entre pipelines

Cette formation a été créée en 2026. Les indicateurs de résultats (taux de satisfaction, taux d’atteinte des objectifs, taux d’assiduité) seront publiés sur cette page à l’issue des premières sessions réalisées.

• Support de cours numérique mis à disposition
• Fichiers de workflows YAML annotés avec exercices et corrections par module
• Environnement : compte GitHub + VS Code + accès à un VPS Ubuntu pour les déploiements
• Pour le distanciel : visioconférence, partage d'écran, chat en direct
• Accès à la plateforme pédagogique LaPolaris (supports, ressources, émargement)

• Feuilles d'émargement signées par demi-journée (présentiel) ou émargement numérique (distanciel)
• Traçabilité des activités pédagogiques réalisées
• Attestation d'assiduité délivrée en fin de formation
• Suivi individuel via la vérification du dépôt GitHub de chaque apprenant en fin de parcours