Intégration continue : construire et tester à chaque commit

« Ça marche sur ma machine » : la phrase que l'intégration continue (continuous integration, CI) veut faire disparaître. Le principe : à chaque modification poussée dans le dépôt, une machine neutre récupère le code, le construit et lance les tests, puis affiche le résultat à toute l'équipe. Une erreur est détectée quelques minutes après avoir été introduite, pas trois semaines plus tard. Cette leçon est théorique.

Ce que vous saurez à la fin : expliquer ce qu'apporte l'intégration continue, lire et écrire un pipeline simple (GitHub Actions et GitLab CI), comprendre où il s'exécute, accélérer un pipeline avec le cache, et protéger la branche principale.

1. Le principe

1. Un développeur pousse une branche ou ouvre une demande de fusion (leçon G.7).
2. La forge (GitHub, GitLab, Gitea…) déclenche un pipeline.
3. Un exécuteur (runner) récupère le code et lance les étapes : installation des dépendances, compilation, analyse statique, tests.
4. Le résultat (vert ou rouge) s'affiche sur le commit et sur la demande de fusion.
5. Une règle empêche de fusionner tant que le pipeline n'est pas vert.

Trois règles d'or : intégrer souvent (de petites branches, fusionnées vite), un pipeline rapide (moins de 10 minutes, sinon personne n'attend le résultat), un pipeline rouge se répare en priorité.

2. GitHub Actions

# .github/workflows/ci.yml
name: ci
on:
  push: {branches: [main]}
  pull_request:
jobs:
  tests:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4          # récupère le code
      - uses: actions/setup-go@v5          # installe Go (avec un cache des modules)
        with: {go-version: '1.25'}
      - run: go vet ./...
      - run: go test -race ./...

• on : les déclencheurs (un push sur main, toute demande de fusion).
• jobs : des tâches, en parallèle par défaut (needs: pour les enchaîner).
• steps : des étapes, soit une commande (run), soit une action réutilisable (uses).

3. GitLab CI

# .gitlab-ci.yml
stages: [verifier, tester]

vet:
  stage: verifier
  image: golang:1.25
  script: [go vet ./...]

tests:
  stage: tester
  image: golang:1.25
  script: [go test -race ./...]
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

Les stages s'exécutent dans l'ordre ; les tâches d'un même stage, en parallèle. Chaque tâche tourne dans un conteneur (image:). Les idées sont les mêmes qu'avec GitHub Actions, seuls les mots changent.

4. Où s'exécute le pipeline ?

Exécuteur	Avantages	Points d'attention
hébergé par la forge	rien à gérer	minutes facturées, pas d'accès au réseau interne
auto-hébergé (machine ou VM)	accès interne, matériel au choix	à maintenir et à isoler
dans Kubernetes (Actions Runner Controller, GitLab Runner pour Kubernetes)	un pod par tâche, mise à l'échelle automatique	droits du pod, construction d'images sans démon privilégié (leçon C.4)

Un exécuteur exécute le code du dépôt : une demande de fusion venant d'un inconnu peut contenir n'importe quoi. Ne branchez jamais un exécuteur auto-hébergé sur un dépôt public sans restrictions, et ne donnez pas de secrets aux pipelines des demandes de fusion externes.

5. Accélérer : cache et artefacts

• Le cache garde d'une exécution à l'autre ce qui coûte cher à recréer (modules Go, node_modules, ~/.m2), avec une clé dérivée du fichier de dépendances (go.sum, package-lock.json).
• Les artefacts transmettent les résultats d'une tâche à la suivante ou les gardent pour consultation (binaire, rapport de tests, couverture).
• Le parallélisme : découper les tests en plusieurs tâches, ou tester plusieurs versions à la fois (strategy.matrix).

6. Protéger la branche principale

Dans les réglages de la forge, sur main :

• interdire les poussées directes : tout passe par une demande de fusion ;
• exiger que les vérifications obligatoires soient vertes ;
• exiger au moins une relecture ;
• interdire la réécriture de l'historique (pas de push --force).

La branche principale reste alors toujours dans un état déployable : la condition du déploiement continu (leçon D.3).

Validez la leçon avec le questionnaire.