infra / github-actions
Concepts CI/CD et GitHub Actions
Explication
Un peu d'histoire
GitHub Actions est lancé par GitHub en 2018, avec une disponibilité générale à partir de novembre 2019. Avant ça, automatiser des tests ou des déploiements demandait de connecter GitHub à un service tiers séparé (Jenkins, Travis CI, CircleCI...). L'idée de GitHub Actions est d'intégrer directement ces capacités de CI/CD dans GitHub, au plus près du code.
Pourquoi apprendre GitHub Actions aujourd'hui
GitHub Actions simplifie énormément l'automatisation d'un projet : lancer les tests à chaque push, construire une image Docker, déployer automatiquement en production, tout ça sans quitter GitHub ni gérer un outil externe. Sa gratuité pour les projets open source et son immense marketplace d'actions réutilisables en ont fait l'un des outils de CI/CD les plus utilisés aujourd'hui — une compétence clé dès qu'un poste touche, même un peu, au DevOps.
Ce que vous allez apprendre
- Comprendre ce que sont réellement la CI (intégration continue) et la CD (déploiement continu)
- Distinguer clairement un workflow, un job et un step, et comment ils s'imbriquent
- Comprendre la différence entre
run:(commande shell brute) etuses:(action réutilisable) - Situer où vivent les fichiers de workflow dans un dépôt GitHub (
.github/workflows/) - Suivre l'exécution d'un workflow directement depuis le terminal avec
gh run watch
Dans quel contexte ?
Une petite équipe de trois développeurs livre son application manuellement depuis un an : chacun lance les tests sur sa machine avant de pousser son code, "en général". Un vendredi, un développeur pressé saute cette étape, pousse un changement cassé, et le site de production tombe en panne pendant deux heures avant que quelqu'un ne s'en aperçoive. GitHub Actions résout exactement ce problème : une machine vérifie systématiquement chaque changement, sans jamais "oublier" ni être pressée par l'heure du déjeuner.
Le problème sans automatisation
D'abord, sans automatisation, chaque changement de code passe par une série d'étapes manuelles répétitives : lancer les tests localement, vérifier que rien n'est cassé, construire l'application, la déployer.
Ce que ça coûte en pratique
Fait à la main, ce processus est lent, source d'oublis, qui n'a jamais oublié de lancer les tests avant de pousser son code, et dépendant de la rigueur individuelle de chaque développeur.
La solution : une machine qui vérifie systématiquement
L'intégration continue (CI) et le déploiement continu (CD) automatisent ce processus : dès qu'un changement est poussé, une machine se charge, systématiquement et sans faille, de vérifier et éventuellement de déployer ce changement.
La CI : vérifier, pas encore déployer
La CI se concentre sur la vérification : à chaque changement, on lance automatiquement les tests, le linter, le build, pour détecter les problèmes le plus tôt possible.
La CD : aller jusqu'au déploiement
La CD va plus loin : une fois ces vérifications passées, le changement est automatiquement déployé, soit immédiatement, soit après une approbation. On peut très bien avoir de la CI sans CD, l'inverse étant en revanche risqué.
Prérequis
Cette leçon ne suppose aucune connaissance préalable de la CI/CD : c'est le point de départ du cours. Un compte GitHub et un dépôt de test suffisent pour suivre les exemples.
La hiérarchie qui structure tout GitHub Actions
Comprendre cette organisation en couches est la clé pour lire n'importe quel fichier de configuration dans ce cours. Un workflow est le fichier de plus haut niveau, déclenché par un événement.
Ce que contient un workflow
Il contient un ou plusieurs jobs, qui s'exécutent en parallèle par défaut, chacun sur sa propre machine virtuelle isolée.
| Niveau | Contient | Exécution |
|---|---|---|
| Workflow | Un ou plusieurs jobs | Déclenché par un événement (on:) |
| Job | Un ou plusieurs steps | En parallèle par défaut, sur une machine isolée |
| Step | Une commande ou une action | Séquentiel, sur la même machine que les autres steps du job |
Ce que contient un job
Chaque job contient des steps, exécutés dans l'ordre, les uns après les autres, sur la même machine, ce qui leur permet de partager des fichiers entre eux, contrairement aux jobs qui sont isolés.
Deux façons d'agir dans un step
Un step peut soit exécuter une commande shell brute, avec run:, soit invoquer une action réutilisable déjà écrite par quelqu'un d'autre, avec uses:.
Bonne pratique
Préfère toujours une action existante et maintenue par la communauté (uses: actions/checkout@v4, par exemple) plutôt que de réécrire la même logique avec plusieurs lignes de run:. C'est plus court, plus fiable, et déjà testé par des milliers d'autres projets.
Le réflexe à adopter
Préfère toujours une action existante et maintenue plutôt que de réécrire toi-même une logique déjà résolue par la communauté.
La prochaine leçon met ce vocabulaire en pratique en construisant un premier workflow complet, du code source jusqu'au build validé.
Commandes & code
CI/CD & GitHub Actions
CI (Intégration Continue) : chaque push déclenche automatiquement tests + build
CD (Déploiement Continu) : chaque changement validé est déployé automatiquement (ou sur approbation)
Workflow (.github/workflows/*.yml)
└── Jobs (s'exécutent en parallèle par défaut, sur des runners séparés)
└── Steps (s'exécutent séquentiellement DANS un job, même machine)
└── Actions ou commandes shell.github/
└── workflows/
├── ci.yml # tests + lint à chaque push/PR
├── deploy.yml # déploiement en production
└── nightly.yml # tâche planifiée (ex: rapport quotidien)# Anatomie minimale d'un workflow
name: CI
on: push # déclencheur (voir leçon dédiée aux triggers)
jobs:
build: # identifiant du job (libre)
runs-on: ubuntu-latest # machine virtuelle fournie par GitHub
steps:
- name: Checkout code
uses: actions/checkout@v4 # action réutilisable, maintenue par GitHub
- name: Run a command
run: echo "Hello CI" # commande shell brute# Runners hébergés disponibles par défaut
# ubuntu-latest, ubuntu-22.04, windows-latest, macos-latest, macos-14 (ARM)...
# Suivre l'exécution des workflows via gh CLI, sans quitter le terminal
gh workflow list
gh run list --workflow=ci.yml
gh run watchRésumé
- Workflow -> Jobs (parallèles) -> Steps (séquentiels) -> Actions ou commandes shell.
- Tout workflow vit dans
.github/workflows/*.yml, déclenché par des événements GitHub. uses:invoque une action réutilisable,run:exécute une commande shell brute.gh run watchsuit une exécution en direct depuis le terminal.
Exercices pratiques
Mission : réparer un pipeline où chaque étape est devenue un job
Objectif : Diagnostiquer un fichier de workflow qui confond jobs et steps, puis le corriger pour rétablir le partage de fichiers entre les étapes.
Contexte
Un collègue vient d'écrire son premier fichier .github/workflows/ci.yml. Persuadé que "plus il y a de jobs, plus c'est rapide", il a transformé chaque étape logique (checkout, installation, tests, build) en un job séparé, plutôt qu'en steps d'un même job. Résultat : le job test échoue systématiquement en ne trouvant ni le code source ni les dépendances installées par le job précédent.
Analyse ce choix, puis propose la structure correcte.