CI/CD & DevOps avec Git

L’écosystème Git moderne

Git est devenu un standard universel. Un écosystème complet s’est construit autour de lui, avec plusieurs plateformes qui enrichissent l’expérience de développement.

GitHub

• Open source, communauté immense
• Pull Requests, GitHub Actions, Codespaces
• Marketplace d’extensions
• Idéal pour l’open source, startups, projets collaboratifs

GitLab

• DevOps intégré de bout en bout
• CI/CD très puissant
• Self-hosting possible
• Idéal pour entreprises et équipes DevOps

Bitbucket

• Intégration native avec Jira
• Écosystème Atlassian complet
• Workflows d’entreprise
• Idéal pour équipes utilisant Jira

Azure DevOps

• Écosystème Microsoft complet
• Pipelines puissants
• Gestion de projet intégrée
• Idéal pour grandes organisations Microsoft

Comparaison des plateformes

Plateforme	Open Source	CI/CD	Self Hosting	Écosystème
GitHub	Excellent	Excellent	Limité	Excellent
GitLab	Très bon	Excellent	Excellent	Très bon
Bitbucket	Bon	Bon	Bon	Très bon
Azure DevOps	Moyen	Excellent	Bon	Excellent

---

GitHub Desktop & GUI Tools

Tout le monde n’est pas à l’aise avec la ligne de commande. Les outils graphiques permettent de visualiser et manipuler Git sans terminal.

GitHub Desktop

Client graphique officiel de GitHub. Il permet de :

• cloner des dépôts
• créer des branches
• faire des commits
• réaliser des Pull Requests
• visualiser l’historique

GitKraken

Client Git avancé avec des fonctionnalités puissantes :

• visualisation graphique des branches
• historique interactif
• gestion des conflits assistée
• intégration GitHub, GitLab, Bitbucket

gitGraph
    commit id: "Initial"
    branch feature/login
    checkout feature/login
    commit id: "Login UI"
    commit id: "Login API"
    checkout main
    merge feature/login id: "Merge"

---

Comprendre les Webhooks

Un Webhook est un mécanisme de notification automatique. Il permet à un système d’envoyer des données en temps réel à un autre système lorsqu’un événement se produit.

Architecture

Push
  ↓
GitHub
  ↓
Webhook (POST HTTP)
  ↓
Discord / Slack / Serveur externe

Exemple concret

Un développeur pousse du code sur main. GitHub envoie immédiatement une notification à Discord. Toute l’équipe reçoit :

Eurin a effectué un push sur main — 3 nouveaux commits

Pourquoi les Webhooks sont-ils utiles ?

• automatisation des notifications
• intégration entre systèmes
• déclenchement de pipelines CI/CD
• synchronisation d’outils

---

Pourquoi automatiser ?

Imaginons le scénario suivant : après chaque push, vous devez :

1. exécuter les tests
2. vérifier la qualité du code
3. construire l’application
4. déployer en production

Faire cela manuellement à chaque modification devient rapidement :

Lent Répétitif Source d'erreurs

L’automatisation résout ces problèmes en exécutant ces tâches de manière fiable et reproductible.

Bénéfices clés

• Gain de temps : les développeurs se concentrent sur le code
• Qualité : les tests sont exécutés systématiquement
• Confiance : chaque commit est vérifié avant d’être livré
• Rapidité : déploiements fréquents et fiables

---

GitHub Actions

GitHub Actions est le moteur d’automatisation intégré à GitHub. Il permet de déclencher des tâches (workflows) en réponse à des événements du dépôt.

Concepts fondamentaux

Concept	Description
Workflow	Processus automatisé défini dans un fichier YAML
Event	Déclencheur (push, pull_request, schedule…)
Job	Ensemble d’étapes exécutées sur un même runner
Step	Commande ou action individuelle
Action	Unité réutilisable (marketplace ou personnalisée)
Runner	Machine virtuelle qui exécute le workflow

Structure d’un fichier de workflow

.github/
└── workflows/
    └── ci.yml

Syntaxe YAML de base

name: CI

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

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Install dependencies
        run: npm install

      - name: Run tests
        run: npm test

Déclencheurs courants

# Déclenchement sur push
on: push

# Sur pull request
on: pull_request

# Planifié (cron)
on:
  schedule:
    - cron: '0 6 * * 1'  # Tous les lundis à 6h UTC

# Manuel
on:
  workflow_dispatch:

# Sur plusieurs événements
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]
  schedule:
    - cron: '0 0 * * 0'

Stratégies de matrix

jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: [18, 20, 22]

    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node-version }}
      - run: npm ci
      - run: npm test

Actions du Marketplace

Le Marketplace GitHub propose des milliers d’actions prêtes à l’emploi :

- uses: actions/checkout@v4              # Récupère le code
- uses: actions/setup-node@v4            # Configure Node.js
- uses: actions/setup-python@v5          # Configure Python
- uses: docker/build-push-action@v5      # Build & push Docker
- uses: actions/cache@v4                 # Met en cache les dépendances
- uses: actions/upload-artifact@v4       # Archive des artéfacts

---

Exemple de pipeline CI complet

name: CI Pipeline

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

env:
  NODE_VERSION: 20

jobs:
  lint:
    name: Lint
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ env.NODE_VERSION }}
          cache: npm
      - run: npm ci
      - run: npm run lint

  test:
    name: Test
    needs: lint
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: [18, 20, 22]
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node-version }}
          cache: npm
      - run: npm ci
      - run: npm test -- --coverage
      - uses: actions/upload-artifact@v4
        with:
          name: coverage-${{ matrix.node-version }}
          path: coverage/

  build:
    name: Build
    needs: test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ env.NODE_VERSION }}
          cache: npm
      - run: npm ci
      - run: npm run build
      - uses: actions/upload-artifact@v4
        with:
          name: build
          path: dist/

  deploy:
    name: Deploy
    needs: build
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main'
    steps:
      - uses: actions/download-artifact@v4
        with:
          name: build
          path: dist/
      - name: Deploy to production
        run: |
          echo "Déploiement en production..."
          # Exemple : scp, rsync, ou appel API

---

GitLab CI/CD

GitLab propose également un moteur d’automatisation puissant, intégré nativement à sa plateforme.

Concepts

• Pipeline : suite d’étapes automatisées
• Job : tâche individuelle (test, build, deploy)
• Runner : machine qui exécute les jobs
• Stage : groupe de jobs exécutés en parallèle

Architecture

Push
  ↓
Pipeline
  ↓
Stages (build → test → deploy)
  ↓
Jobs
  ↓
Runners
  ↓
Résultat

Exemple .gitlab-ci.yml

stages:
  - build
  - test
  - deploy

build-app:
  stage: build
  image: node:20
  script:
    - npm ci
    - npm run build
  artifacts:
    paths:
      - dist/

test-app:
  stage: test
  image: node:20
  script:
    - npm ci
    - npm test

deploy-production:
  stage: deploy
  image: alpine:latest
  script:
    - echo "Déploiement en production..."
  only:
    - main

Comparaison GitHub Actions vs GitLab CI/CD

Caractéristique	GitHub Actions	GitLab CI/CD
Fichier de config	.github/workflows/*.yml	.gitlab-ci.yml
Runners	Hébergés ou auto-hébergés	Hébergés ou auto-hébergés
Marketplace	Oui (GitHub Marketplace)	Non (templates)
Matrice	strategy.matrix	parallel:matrix
Cache	actions/cache	cache:
Artefacts	actions/upload-artifact	artifacts:

---

Supply Chain Security

Une application moderne dépend de bibliothèques, frameworks et packages. Ces dépendances peuvent contenir des vulnérabilités, des secrets exposés ou du code malveillant. La sécurité ne concerne plus uniquement votre code, mais tout l’écosystème.

GitHub Secrets

Stocker des secrets dans le code est une mauvaise pratique.

// ❌ Mauvaise pratique
const API_KEY = "sk-1234567890abcdef";

# ✅ Bonne pratique : utiliser GitHub Secrets
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Deploy with secret
        run: ./deploy.sh
        env:
          API_KEY: ${{ secrets.API_KEY }}

Les secrets sont chiffrés et injectés comme variables d’environnement au moment de l’exécution.

Dependabot

Dependabot surveille automatiquement vos dépendances :

• détecte les vulnérabilités connues
• propose des mises à jour correctives
• crée automatiquement des Pull Requests

.github/dependabot.yml

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    open-pull-requests-limit: 10

  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "monthly"

Secret Scanning

GitHub peut détecter automatiquement les secrets exposés dans votre code :

• tokens d’authentification
• clés API (AWS, OpenAI, GitHub…)
• certificats privés
• mots de passe

Dès qu’un secret est détecté, GitHub alerte l’équipe et peut bloquer le push.

Signed Commits

Un commit signé cryptographiquement permet de vérifier :

• l’identité : l’auteur est bien qui il prétend être
• l’authenticité : le commit n’a pas été modifié
• l’intégrité : le contenu est exactement ce qui a été signé

git config --global user.signingkey KEY_ID
git config --global commit.gpgsign true
git commit -S -m "feat: ajout authentification"

Branch Protection Rules

Empêche les actions dangereuses sur les branches critiques :

• interdire les push directs sur main
• exiger des reviews avant merge
• exiger le passage des tests CI
• exiger les commits signés
• limiter les permissions aux utilisateurs autorisés

Least Privilege

Principe fondamental : donner uniquement les permissions nécessaires, jamais plus.

jobs:
  test:
    runs-on: ubuntu-latest
    permissions:
      contents: read        # Lecture seule
      issues: write         # Écriture sur les issues
      pull-requests: write  # Écriture sur les PR

Vue globale de la supply chain sécurisée

Développeur
    ↓
Push (Signed Commit)
    ↓
GitHub (Secret Scanning)
    ↓
GitHub Actions (CI/CD)
    ↓
Tests → Build → Deploy
    ↓
Notifications (Webhooks)
    ↓
Dependabot (surveillance continue)

---

Atelier pratique

Objectif

Créer un pipeline CI/CD complet pour le projet Operation Sentinel.

Exercice 1 : Créer la structure

Créez le répertoire de workflow :

mkdir -p .github/workflows

Exercice 2 : Créer un fichier CI

Créez .github/workflows/ci.yml avec le contenu suivant :

name: Operation Sentinel CI

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

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: npm

      - name: Install dependencies
        run: npm ci

      - name: Run lint
        run: npm run lint

      - name: Run tests
        run: npm test

      - name: Build project
        run: npm run build

Exercice 3 : Configurer un GitHub Secret

1. Allez dans Settings > Secrets and variables > Actions
2. Cliquez sur New repository secret
3. Ajoutez une clé nommée DEPLOY_TOKEN avec une valeur factice
4. Modifiez votre workflow pour utiliser le secret :

      - name: Deploy
        run: ./deploy.sh
        env:
          TOKEN: ${{ secrets.DEPLOY_TOKEN }}

Exercice 4 : Configurer Dependabot

Créez .github/dependabot.yml :

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "monthly"

Exercice 5 : Configurer Branch Protection

1. Allez dans Settings > Branches
2. Ajoutez une règle pour main :
   • Require pull request reviews (1 approbation)
   • Require status checks (le job test doit passer)
   • Require signed commits
   • Restrict push access

Mini Challenge

Construisez un pipeline complet qui exécute la chaîne suivante :

Push
  ↓
Lint
  ↓
Test
  ↓
Build
  ↓
Notification (via Webhook Discord/Slack)

1. Créer le workflow — Ajoutez un job notify à la fin du pipeline existant.

2. Ajouter une action de notification — Utilisez action-slack/notify ou Ilshidur/action-discord.

3. Configurer le secret — Stockez le webhook URL dans un GitHub Secret.

4. Pousser le code — Déclenchez le pipeline et vérifiez la notification.

name: Pipeline Complet

on:
  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 test
      - run: npm run build

  notify:
    needs: quality
    runs-on: ubuntu-latest
    steps:
      - name: Send notification
        uses: Ilshidur/action-discord@master
        env:
          DISCORD_WEBHOOK: ${{ secrets.DISCORD_WEBHOOK }}
        with:
          args: "✅ Pipeline terminé avec succès !"

---

Questions de réflexion

1. Pourquoi automatiser les tâches répétitives ?
2. Pourquoi lancer les tests automatiquement à chaque push ?
3. Pourquoi protéger les secrets plutôt que les coder en dur ?
4. Pourquoi vérifier régulièrement les dépendances ?
5. Pourquoi le DevOps est-il devenu indispensable dans l’industrie ?

---

À retenir

L’ingénierie moderne ne consiste plus uniquement à écrire du code. Elle consiste également à :

• automatiser les tâches répétitives
• sécuriser la supply chain logicielle
• collaborer avec des outils intégrés
• livrer rapidement et en confiance
• réduire les risques à chaque étape

Le workflow moderne devient :

Code → Git → GitHub → Tests → Build → Deploy → Monitoring

Documentation officielle GitHub Actions

---

Fiches de révision

Question

Quelle est la syntaxe de base d'un workflow GitHub Actions ?

Cliquer pour révéler la réponse

Réponse

name → on → jobs → runs-on → steps avec uses/run

Cliquer pour voir la question

Question

Quels événements peuvent déclencher une CI ?

Cliquer pour révéler la réponse

Réponse

push, pull_request, schedule, workflow_dispatch, release

Cliquer pour voir la question

Question

Quel est le rôle d'un Webhook GitHub ?

Cliquer pour révéler la réponse

Réponse

Notifier un système externe en temps réel lors d'un événement du dépôt

Cliquer pour voir la question

Question

Que fait Dependabot ?

Cliquer pour révéler la réponse

Réponse

Analyse les dépendances et ouvre automatiquement des PR pour les mettre à jour

Cliquer pour voir la question

---

Évaluation des connaissances

Qu'est-ce que le CI/CD ?

A Un langage de programmation B Une pratique d'automatisation des tests, builds et déploiements C Un outil de gestion de bases de données D Un framework JavaScript

Quel fichier définit un workflow GitHub Actions ?

A docker-compose.yml B .github/workflows/*.yml C package.json D README.md

Quel est le rôle d'un Webhook ?

A Stocker des mots de passe B Envoyer des notifications automatiques en temps réel à un autre système C Compresser les fichiers du dépôt D Générer des tokens d'authentification

Quel outil surveille automatiquement les dépendances pour détecter les vulnérabilités ?

A Webpack B Dependabot C Babel D ESLint

Pourquoi est-il déconseillé de coder un secret en dur dans le code source ?

A C'est plus lent à exécuter B Le secret peut fuiter dans l'historique Git et être exposé C Les secrets codés en dur ne fonctionnent pas D Cela augmente la taille du dépôt