build automatisé et déploiement simple

Objectifs

Comprendre l’étape de “build” et son rôle dans un pipeline CI/CD.
Automatiser la construction d’un artefact, comme une image Docker.
Effectuer un déploiement simple et automatisé, par exemple vers GitHub Pages.
Gérer les secrets de manière sécurisée.

L’étape de Build : Créer l’artefact

Une fois que le code est testé, l’étape de build consiste à créer le “paquet” qui sera déployé. Cet artefact doit être autonome et reproductible.

Pour une application web moderne, l’artefact le plus courant est une image Docker.
Pour un site statique, ce sont les fichiers HTML/CSS/JS prêts à être servis.
Pour un programme compilé, c’est le binaire exécutable.

Automatiser le build d’une image Docker

Voici un exemple de job GitHub Actions qui construit une image Docker et la pousse vers le GitHub Container Registry (GHCR), un registre d’images privé gratuit pour vos projets.

# ... (dans votre fichier de workflow)
jobs:
  # ... (votre job de test)
  
  build_and_push:
    # Ce job ne démarre que si le job 'test' a réussi
    needs: test
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write # Permission pour pousser l'image sur GHCR

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

      - name: Connexion au GitHub Container Registry
        uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - name: Build et Push de l'image Docker
        uses: docker/build-push-action@v5
        with:
          context: .
          push: true
          # Le nom de l'image, ex: ghcr.io/votre-user/votre-repo:latest
          tags: ghcr.io/${{ github.repository }}:${{ github.sha }}

Déploiement Continu (CD)

Le déploiement continu est la pratique qui consiste à déployer automatiquement en production (ou sur un autre environnement) chaque changement qui a passé avec succès toutes les étapes de la CI.

Déploiement simple sur GitHub Pages

Pour un site statique, GitHub Pages est une solution d’hébergement gratuite et parfaitement intégrée.

# Job pour déployer un site statique sur GitHub Pages
jobs:
  deploy:
    # ... (dépend du job de build de votre site)
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pages: write      # Permissions pour déployer sur Pages
      id-token: write   # Permissions pour l'authentification
    
    steps:
      - name: Récupérer l'artefact du site
        uses: actions/download-artifact@v4
        with:
          name: site-statique # Nom de l'artefact uploadé par le job de build

      - name: Déployer sur GitHub Pages
        uses: actions/deploy-pages@v4

Gestion des secrets

Un pipeline a souvent besoin de secrets (mots de passe, clés d’API, tokens). Ne les écrivez jamais en clair dans votre fichier YAML !

Utilisez les Secrets de votre dépôt GitHub (Settings > Secrets and variables > Actions).

Vous créez un secret avec un nom (ex: DOCKER_PASSWORD).
Vous pouvez ensuite l’utiliser dans votre workflow avec la syntaxe ${{ secrets.NOM_DU_SECRET }}. GitHub s’assure qu’il n’apparaîtra jamais dans les logs.

Bonnes pratiques

Séparez les jobs : Ayez des jobs distincts pour le test, le build et le déploiement. Utilisez needs pour les enchaîner.
Versionnez vos artefacts : Taguez vos images Docker avec le hash du commit (${{ github.sha }}) ou un tag Git, pas seulement latest. Cela garantit la traçabilité.
Commencez par un déploiement manuel : Avant d’automatiser le déploiement en production, mettez en place un déclenchement manuel (workflow_dispatch) pour garder le contrôle.

Pièges courants

Laisser des secrets dans les logs : Faites attention à ce que vos commandes (echo, etc.) n’affichent pas accidentellement une variable contenant un secret.
Déployer une branche de feature en production : Assurez-vous que votre workflow de déploiement ne se déclenche que sur la branche main.

Exercices

Job de build factice :
- Ajoutez un nouveau job à votre workflow, qui dépend du job de test (needs: test).
- Ce job doit contenir une seule étape qui exécute echo "Construction de l'artefact...".
- Observez comment il ne s’exécute que si les tests réussissent.
Utiliser un secret :
- Dans les paramètres de votre dépôt GitHub, créez un nouveau secret nommé MON_SECRET avec une valeur de votre choix.
- Créez un workflow qui tente d’afficher ce secret avec run: echo "Le secret est ${{ secrets.MON_SECRET }}".
- Observez dans les logs que GitHub a automatiquement masqué la valeur avec des astérisques (***).

Menu