⚡ GitHub Actions — CI/CD natif GitHub

Objets clés

Positionnement rapide (lecture DevOps)

Permissions : la base de la sécurité (principe)

Pattern conseillé:
- limiter les permissions par défaut au strict nécessaire
- séparer “build/test” vs “deploy”
- secrets uniquement au job qui en a besoin (env / org / repo)
        

Artifacts : evidence + outputs

• Publier reports de tests, coverage, logs (debug rapide).
• Publier un artefact “release” immuable (zip, wheel, image taguée) → “build once, deploy many”.

Concurrency : éviter les doublons (principe)

Objectif:
- si 5 push sur une PR: annuler les anciens runs
- protéger “deploy prod”: un seul déploiement à la fois
        

Exemple Django (lint + tests)

name: Django CI
on:
  pull_request:
  push:
    branches: [ "main" ]

jobs:
  ci:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4
      - name: Setup Python
        uses: actions/setup-python@v5
        with:
          python-version: "3.12"
      - name: Install
        run: |
          python -m pip install -U pip
          pip install -r requirements.txt
      - name: Lint + Tests
        run: |
          ruff check .
          pytest -q --maxfail=1
        

Matrix (multi-versions) — concept

strategy:
  matrix:
    python: ["3.10","3.11","3.12"]
steps:
  - uses: actions/setup-python@v5
    with:
      python-version: $
        

Conditions (if) — concept

- name: Deploy only on main
  if: github.ref == 'refs/heads/main'
  run: ./deploy.sh
        

Supply chain : “version pinning” (principe)

• Éviter @main / @master sur les actions critiques.
• Pin sur version tag + (idéalement) digest/sha quand tu veux verrouiller.
• Limiter permissions du workflow au strict nécessaire.

Gouvernance (teams)

• Catalogue “approved actions” (liste blanche), surtout pour les repos sensibles.
• Workflows templates au niveau organisation (standardisation).
• Scan régulier des workflows (permissions/secrets/3rd party actions).

Appeler un reusable workflow

GitHub documente l’appel via uses au niveau job (pas dans steps). :contentReference[oaicite:16]{index=16}

jobs:
  ci:
    uses: org/repo/.github/workflows/ci.yml@v1
        

Composite action

GitHub explique comment créer une composite action (pack de steps réutilisables). :contentReference[oaicite:17]{index=17}

steps:
  - uses: ./.github/actions/my-composite
        

Gestion : labels, services, lifecycle

GitHub documente la gestion des self-hosted runners (labels, config service, etc.). :contentReference[oaicite:19]{index=19}

Bonnes pratiques:
- runners dédiés "prod-deploy" (isolation)
- labels: linux-x64, docker, highmem
- runner comme service (auto-start)
- patching + rotation + monitoring
        

Usage YAML

jobs:
  build:
    runs-on: ubuntu-latest
  deploy_private:
    runs-on: [self-hosted, linux, prod-deploy]
        

Required reviewers (approvals)

GitHub indique que les reviewers requis protègent les secrets d’environnement : un job ne peut pas accéder aux secrets tant que l’approbation n’est pas accordée. :contentReference[oaicite:21]{index=21}

Pattern:
- environment: prod
- required reviewers: Release Managers
- restrict deploy branches: main + tags v*
        

Exemple (concept)

jobs:
  deploy_prod:
    if: github.ref == 'refs/heads/main'
    environment: prod
    runs-on: ubuntu-latest
    steps:
      - run: ./deploy.sh
        

OIDC : authentifier sans secrets long-lived

GitHub Actions peut utiliser des tokens OIDC pour s’authentifier auprès de cloud providers au lieu de secrets. :contentReference[oaicite:23]{index=23}

Pattern:
- job demande un token OIDC
- trust policy côté cloud (AWS/Azure/GCP)
- permissions minimales par environnement
        

Environments + protection rules

GitHub recommande des protection rules sur les environments, notamment quand on les utilise avec OIDC. :contentReference[oaicite:24]{index=24}

Prod:
- required reviewers
- branches/tags autorisés
- secrets uniquement prod
        

Runners self-hosted : surface d’attaque

GitHub décrit les self-hosted runners et leur gestion (labels, service, etc.) : c’est à toi de sécuriser l’OS, le réseau, et les accès. :contentReference[oaicite:25]{index=25}

Hardening minimal:
- isolation réseau (VPC/subnet dédiée)
- runners dédiés prod
- patching + rotation
- monitoring + logs
        

DRY & standardisation

GitHub pousse la réutilisation via reusable workflows et composite actions. :contentReference[oaicite:32]{index=32}

Pattern org:
- repo "ci-templates"
- workflows réutilisables: ci.yml, release.yml, deploy.yml
- composite actions: setup, lint, security-scan
        

Phrase CV-ready

Industrialisation CI/CD avec GitHub Actions : workflows YAML (events push/PR/schedule),
jobs parallélisés, standardisation via reusable workflows/composite actions, déploiements sécurisés
par environments + required reviewers, et authentification cloud via OIDC (suppression de clés statiques),
avec runners self-hosted isolés pour déploiements sensibles.
        

Stratégie progressive

1. Pilote sur 1–2 repos (non critique) → reproduire “CI identique”.
2. Mettre des templates : reusable workflows + conventions.
3. Définir une politique sécurité : secrets, environments, approbations.
4. Basculer par lots (team/repo), puis ajouter optimisations (cache, concurrency).
5. Si on-prem: déployer self-hosted runners avec hardening. :contentReference[oaicite:37]{index=37}

Pièges fréquents

• Self-hosted runner “fourre-tout” (trop de repos) → privilégier isolation par groupes/labels.
• Secrets trop exposés (au niveau repo alors que prod devrait être environment + approvals). :contentReference[oaicite:38]{index=38}
• Pas d’OIDC → accumulation de clés statiques (risque). :contentReference[oaicite:39]{index=39}
• Pas de DRY → duplication YAML, drift → passer sur reuse/composite. :contentReference[oaicite:40]{index=40}

Checklist