GitHub Actions et automatisation

Tu sais pusher du code, créer des PRs, collaborer sur GitHub. Mais à chaque merge, tu lances les tests à la main ? Tu déploies en SSH avec un script bricolé ? C’est là que GitHub Actions entre en jeu : ton pipeline CI/CD, directement intégré à ton repo, déclenché automatiquement à chaque événement Git.

Dans ce chapitre, tu vas apprendre à écrire des workflows qui testent, buildent et déploient ton code — sans quitter GitHub.

Pourquoi GitHub Actions change la donne

En entreprise, personne ne devrait merger du code non testé. Personne ne devrait déployer manuellement un vendredi soir. L’automatisation CI/CD résout ces deux problèmes.

GitHub Actions est la solution native de GitHub. Pas besoin de configurer un Jenkins, pas de serveur CI séparé. Tout vit dans ton repo, au format YAML, versionné avec ton code.

🔥 Cas réel : Une startup SaaS avait un process de déploiement manuel — 45 minutes par release, avec des oublis fréquents (migrations DB, invalidation de cache). Après la mise en place de GitHub Actions : déploiement en 8 minutes, zéro intervention humaine, rollback automatique si les health checks échouent.

Les avantages concrets :

• Tests automatiques sur chaque PR — plus de “ça marche sur ma machine”
• Déploiement reproductible — même process à chaque fois
• Feedback rapide — tu sais en 3 minutes si ton commit casse quelque chose
• Gratuit pour les repos publics, 2000 minutes/mois pour les privés

🧠 À retenir : Le CI/CD n’est pas un luxe. C’est le filet de sécurité minimum pour toute équipe qui livre du code en production.

Comprendre l’architecture d’un workflow

Un workflow GitHub Actions repose sur quatre concepts imbriqués :

• Workflow : un fichier YAML dans .github/workflows/. Un repo peut en avoir plusieurs (CI, déploiement, lint…).
• Event : ce qui déclenche le workflow — un push, une pull_request, un tag, un cron, ou un déclenchement manuel.
• Job : un ensemble d’étapes qui s’exécutent sur une VM (appelée runner). Les jobs tournent en parallèle par défaut.
• Step : une commande (run) ou une action réutilisable (uses) à l’intérieur d’un job.

Voici la structure de dossier attendue par GitHub :

.github/
└── workflows/
    ├── ci.yaml         # Tests automatiques
    ├── deploy.yaml     # Déploiement
    └── lint.yaml       # Vérification du code

💡 Tip DevOps : Sépare tes workflows par responsabilité. Un workflow pour le CI, un pour le déploiement, un pour la maintenance. Ça évite les fichiers YAML de 200 lignes impossibles à débugger.

Écrire ton premier workflow

Commençons par un pipeline CI classique. Ce workflow se déclenche sur chaque push et chaque PR vers main. Il checkout le code, installe les dépendances, puis lance le linter et les tests.

# .github/workflows/ci.yaml
name: CI Pipeline

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  test:
    name: Tests & Lint
    runs-on: ubuntu-latest

    steps:
      - name: Checkout du code
        uses: actions/checkout@v4

      - name: Setup Python
        uses: actions/setup-python@v5
        with:
          python-version: "3.12"

      - name: Installation des dépendances
        run: |
          pip install -r requirements.txt
          pip install pytest flake8

      - name: Linting
        run: flake8 . --max-line-length=120

      - name: Tests
        run: pytest -v --tb=short

⚠️ Attention : L’indentation YAML est critique. Une tabulation au lieu d’espaces, un mauvais niveau d’indentation, et ton workflow ne se lance tout simplement pas. Utilise toujours 2 espaces.

Les événements déclencheurs les plus utilisés méritent qu’on s’y attarde. Voici les patterns que tu croiseras le plus souvent en entreprise :

on:
  push:
    branches: [main, develop]
    paths:
      - 'src/**'              # Uniquement si src/ change

  pull_request:
    types: [opened, synchronize, reopened]

  push:
    tags:
      - 'v*'                  # Tags de release (v1.0.0, v2.3.1...)

  workflow_dispatch:           # Déclenchement manuel depuis l'UI
    inputs:
      environment:
        description: 'Environnement cible'
        required: true
        type: choice
        options: [staging, production]

  schedule:
    - cron: '0 6 * * 1-5'    # Lundi-vendredi à 6h UTC

💡 Tip DevOps : Utilise paths pour éviter de déclencher le CI quand tu modifies uniquement le README ou la doc. Ça économise des minutes de build.

Techniques avancées : matrice, secrets et déploiement

En production, tu as besoin de tester sur plusieurs versions, gérer des credentials, et enchaîner les environnements. Voici un workflow complet qui combine ces trois besoins.

La stratégie matrix permet de tester ton code sur plusieurs versions en parallèle. Les secrets stockent tes credentials de manière sécurisée. Et le mot-clé needs crée des dépendances entre jobs.

name: CI + Deploy

on:
  push:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        python-version: ["3.10", "3.11", "3.12"]
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: ${{ matrix.python-version }}
      - run: pip install -r requirements.txt
      - run: pytest --cov=app --cov-report=xml

  deploy-staging:
    needs: test
    runs-on: ubuntu-latest
    environment: staging
    steps:
      - uses: actions/checkout@v4
      - name: Deploy staging
        run: ./scripts/deploy.sh staging
        env:
          SSH_KEY: ${{ secrets.STAGING_SSH_KEY }}
          API_URL: ${{ vars.STAGING_API_URL }}

  deploy-prod:
    needs: deploy-staging
    runs-on: ubuntu-latest
    environment: production
    steps:
      - uses: actions/checkout@v4
      - name: Deploy production
        run: ./scripts/deploy.sh production
        env:
          SSH_KEY: ${{ secrets.PROD_SSH_KEY }}

Pour ajouter un secret : Repo → Settings → Secrets and variables → Actions → New repository secret. Les secrets sont automatiquement masqués dans les logs — GitHub remplace leur valeur par ***.

⚠️ Attention : Ne mets jamais de credentials en dur dans un workflow. Pas de mot de passe, pas de token, pas de clé SSH dans le YAML. Toujours ${{ secrets.NOM }}.

Cas concret : pipeline CI/CD d’une app Node.js en entreprise

🔥 Cas réel : Voici le workflow typique d’une équipe de 8 développeurs sur une API Node.js. Le CI tourne sur chaque PR, le déploiement se fait automatiquement après merge sur main.

name: Production Pipeline

on:
  pull_request:
    branches: [main]
  push:
    branches: [main]

jobs:
  quality:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: 'npm'
      - run: npm ci
      - run: npm run lint
      - run: npm run test:unit -- --coverage
      - run: npm run test:integration
        env:
          DATABASE_URL: postgres://localhost:5432/test

    services:
      postgres:
        image: postgres:16
        env:
          POSTGRES_DB: test
          POSTGRES_PASSWORD: test
        ports:
          - 5432:5432

  deploy:
    if: github.event_name == 'push' && github.ref == 'refs/heads/main'
    needs: quality
    runs-on: ubuntu-latest
    environment: production
    steps:
      - uses: actions/checkout@v4
      - name: Build Docker image
        run: docker build -t ${{ secrets.REGISTRY }}/api:${{ github.sha }} .
      - name: Push & Deploy
        run: |
          echo "${{ secrets.REGISTRY_TOKEN }}" | docker login -u deploy --password-stdin
          docker push ${{ secrets.REGISTRY }}/api:${{ github.sha }}
          kubectl set image deployment/api api=${{ secrets.REGISTRY }}/api:${{ github.sha }}

Ce pipeline illustre plusieurs bonnes pratiques : le cache npm accélère les builds, les services permettent de lancer une base Postgres pour les tests d’intégration, et le déploiement ne se déclenche que sur un push effectif sur main (pas sur les PRs).

🧠 À retenir : Le if conditionnel est ton meilleur ami. Il te permet d’avoir un seul workflow pour le CI et le CD, avec des jobs qui ne s’exécutent que dans le bon contexte.

Pièges fréquents et comment les éviter

Le workflow qui ne se déclenche pas. Vérifie trois choses : le fichier est bien dans .github/workflows/, le nom de branche dans on.push.branches correspond exactement, et le YAML est valide (pas de tabulations).

Les tests passent en local mais échouent en CI. La VM du runner part de zéro à chaque run. Si tu dépends d’une variable d’environnement locale, d’un fichier .env, ou d’un service (Redis, Postgres), il faut les déclarer explicitement dans le workflow.

Le build prend 15 minutes. Utilise le cache. actions/cache pour pip/npm, ou les options cache intégrées aux actions setup. Un build bien caché passe de 12 minutes à 3.

Les secrets qui fuient. Ne fais jamais echo ${{ secrets.TOKEN }} pour débugger. Même si GitHub masque la valeur, des encodages (base64, URL-encode) peuvent la révéler.

Pour débugger un workflow depuis le terminal, la CLI gh est indispensable :

# Voir les derniers runs
gh run list

# Consulter les logs d'un run en échec
gh run view 123456 --log-failed

# Relancer un run
gh run rewatch 123456

# Déclencher manuellement un workflow
gh workflow run ci.yaml

💡 Tip DevOps : Ajoute gh run watch après un push pour suivre l’exécution en temps réel dans ton terminal. Plus rapide que de rafraîchir l’UI GitHub.

Exercice pratique

Objectif : Crée un pipeline CI/CD complet pour un projet Python.

1. Crée un repo avec un fichier app.py et un test_app.py basique
2. Écris un workflow .github/workflows/ci.yaml qui :
   • Se déclenche sur push et PR vers main
   • Teste sur Python 3.11 et 3.12 (matrice)
   • Lance flake8 pour le linting
   • Lance pytest pour les tests
3. Ajoute un job de déploiement qui ne s’exécute que sur push vers main (pas sur les PRs), avec needs: test
4. Configure une branch protection rule sur main qui exige le passage du CI

Bonus : Ajoute un step qui utilise actions/cache pour accélérer l’installation des dépendances pip.

🧠 À retenir :

• Un workflow = un fichier YAML dans .github/workflows/
• on définit quand ça se déclenche, jobs définit quoi faire
• Les secrets ne vont jamais dans le code — toujours dans Settings → Secrets
• needs enchaîne les jobs, if les conditionne
• La CLI gh est ton copilot pour débugger les Actions depuis le terminal
• Commence simple (un job, un test), puis itère — un pipeline de 500 lignes dès le jour 1, c’est la garantie de ne jamais le maintenir