CI/CD pour Django : de 0 à la production en 30 minutes avec GitHub Actions

Un pipeline CI/CD robuste est l'investissement le plus rentable d'un projet. J'ai vu des équipes senior passer des heures à déboguer des régressions qui auraient été détectées en 2 minutes par des tests automatisés. Voici comment ne pas faire cette erreur.

Ce que votre pipeline doit faire (dans cet ordre)

1. Lint : ruff check + ruff format --check — détecte les erreurs syntaxiques et de style
2. Tests : pytest avec coverage — valide le comportement
3. Sécurité : bandit (vulnérabilités Python) + safety (dépendances CVE)
4. Build Docker : construit l'image de production
5. Deploy : seulement si tout ce qui précède est vert, seulement sur main

Le workflow GitHub Actions complet

name: CI/CD Django
on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    services:
      postgres:
        image: postgres:16
        env:
          POSTGRES_PASSWORD: test
        options: >-
          --health-cmd pg_isready
          --health-interval 10s
    env:
      DATABASE_URL: postgres://postgres:test@localhost/test
      DJANGO_SECRET_KEY: ci-only-key
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"
          cache: pip
      - run: pip install -r requirements.txt
      - run: ruff check .
      - run: pytest --cov=. --cov-report=xml -n auto
      - run: bandit -r . -x tests/

Optimiser les temps de build : de 8 min à 2 min

- uses: actions/cache@v4
  with:
    path: ~/.cache/pip
    key: ${{ runner.os }}-pip-${{ hashFiles('requirements.txt') }}

Ce cache seul réduit l'étape d'installation de 3 min à 15 secondes quand requirements.txt n'a pas changé. Ajoutez pytest -n auto pour les tests en parallèle.

Les 5 erreurs CI les plus fréquentes

1. Tests qui passent en CI mais échouent en prod : la CI utilise SQLite, la prod PostgreSQL. Toujours utiliser PostgreSQL en CI via service Docker.
2. Variables d'environnement manquantes : créez un settings_ci.py minimal avec toutes les variables requises.
3. Tests dépendants de l'ordre : utilisez pytest-randomly pour détecter ces cas.
4. Secrets en clair dans les logs : vérifiez les logs avant de merger.
5. Migrations non commitées : ajoutez python manage.py migrate --check dans la CI.

Métriques à surveiller après 3 mois

• Durée moyenne du pipeline : < 8 minutes
• Taux d'échec : < 5% (les échecs légitimes doivent être rares)
• Couverture de tests : en hausse continue, jamais en baisse

Un pipeline CI lent ou instable sera contourné. Investissez dans sa fiabilité.