Fondamentaux du CI/CD¶

Anatomie d'un pipeline¶

Un pipeline CI/CD est une sequence d'étapes automatisees declenchee par un événement (push, tag, merge request). Chaque étape produit un résultat qui alimente la suivante.

graph LR
    Trigger --> Build --> Test --> Scan --> Package --> Deploy
    Deploy --> Production
    Package --> Registre["Registre (Harbor)"]
    Scan --> Rapport_sec["Rapport securite (Trivy)"]
    Test --> Rapport_test["Rapport tests + couverture"]
    Build --> Artefact["Artefact compile"]
    Trigger --> Evenement["Push / Tag / Merge<br/>Cron / Webhook"]

Étapes détaillées¶

Pipeline-as-Code¶

Le pipeline est defini dans un fichier YAML versionne dans le dépôt. Chaque modification du pipeline suit le même workflow que le code : review, merge, historique.

Fichier de workflow Gitea Actions¶

# .gitea/workflows/ci.yaml
name: CI Pipeline
on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build
        run: make build
      - name: Test
        run: make test
      - name: Scan
        run: trivy fs --exit-code 1 .

Avantages du pipeline-as-code¶

Runners, agents et workers¶

Le runner est le composant qui execute les étapes du pipeline. Il reçoit les jobs du serveur CI, execute les commandes dans un environnement isole et renvoie les résultats.

Architecture runner¶

graph LR
    CI["Serveur CI<br/>(Gitea)<br/><br/>File de jobs<br/>Resultats<br/>Artefacts"] <-->|gRPC| R1["Runner #1<br/>(act runner)<br/>Conteneur ephemere"]
    CI <-->|gRPC| R2["Runner #2<br/>(act runner)<br/>VM persistante"]

Ephemere vs persistant¶

Passage d'artefacts entre étapes¶

Les étapes d'un pipeline doivent partager des artefacts (binaires compiles, rapports de tests, images). Plusieurs mécanismes existent :

# Exemple : partage d'artefacts entre jobs
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: make build
      - uses: actions/upload-artifact@v4
        with:
          name: binary
          path: ./bin/app

  deploy:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - uses: actions/download-artifact@v4
        with:
          name: binary
      - run: ./deploy.sh

Injection de secrets¶

Les secrets (tokens, credentials, cles) ne doivent jamais apparaître dans le code du pipeline. Ils sont injectes a l'execution.

Méthodes d'injection¶

Stratégies de déploiement¶

Le déploiement est l'étape la plus critique. Plusieurs stratégies permettent de limiter l'impact d'une régression.

Comparaison des stratégies¶

Rolling update¶

graph TD
    T0["Temps 0 : v1 v1 v1 v1"]
    T1["Temps 1 : <b>v2</b> v1 v1 v1 — une instance remplacee"]
    T2["Temps 2 : <b>v2 v2</b> v1 v1"]
    T3["Temps 3 : <b>v2 v2 v2</b> v1"]
    T4["Temps 4 : <b>v2 v2 v2 v2</b> — deploiement termine"]
    T0 --> T1 --> T2 --> T3 --> T4

Blue/Green¶

graph LR
    subgraph Avant bascule
        T1["Traffic"] -->|100%| Blue1["Blue (v1) — actif"]
        Green1["Green (v2) — pret, pas de trafic"]
    end
    subgraph Apres bascule
        T2["Traffic"] -->|100%| Green2["Green (v2) — actif"]
        Blue2["Blue (v1) — standby"]
    end

Canary¶

graph LR
    Traffic["Traffic"]
    Traffic -->|95%| Stable["Stable v1"]
    Traffic -->|5%| Canary["Canary v2<br/>observation des metriques"]

Modèle GitOps¶

GitOps est un paradigme de déploiement ou l'état desire de l'infrastructure est declare dans un dépôt Git. Un opérateur (Flux v2) reconcilie en permanence l'état reel du cluster avec l'état declare.

Principes fondamentaux¶

Boucle de reconciliation¶

graph LR
    Git["Depot Git
    etat desire

    manifests/
    app/deployment.yaml"] --> FluxV2["Flux v2
    operateur

    Compare desired
    vs actual
    Sync si diff"]
    FluxV2 --> K8s["Cluster K8s
    etat reel

    Pods, Services,
    ConfigMaps..."]
    FluxV2 --> Drift{"Drift detecte ?"}
    Drift --> Sync["Sync automatique
    ou alerte"]

Pull vs Push deployment¶

Recapitulatif¶