Bonjour ! Je suis

Federico Calò

Sviluppatore Software | Divulgatore Tecnico

Creo applicazioni web moderne e strumenti digitali personalizzati per aiutare le attività a crescere attraverso l'innovazione tecnologica. La mia passione è unire informatica ed economia per generare valore reale.

Contactez-moi

À Propos

La mia passione per l'informatica è nata tra i banchi dell'Istituto Tecnico Commerciale di Maglie, dove ho scoperto il potere della programmazione e il fascino di creare soluzioni digitali. Fin da subito, ho capito che l'informatica non era solo codice, ma uno strumento straordinario per trasformare idee in realtà.

Durante gli studi superiori in Sistemi Informativi Aziendali, ho iniziato a intrecciare informatica ed economia, comprendendo come la tecnologia possa essere il motore della crescita per qualsiasi attività. Questa visione mi ha accompagnato all'Università degli Studi di Bari, dove ho conseguito la Laurea in Informatica, approfondendo le mie competenze tecniche e la mia passione per lo sviluppo software.

Oggi metto questa esperienza al servizio di imprese, professionisti e startup, creando soluzioni digitali su misura che automatizzano processi, ottimizzano risorse e aprono nuove opportunità di business. Perché la vera innovazione inizia quando la tecnologia incontra le esigenze reali delle persone.

Mes Compétences

Analisi Dati & Modelli Previsionali

Trasformo i dati in insights strategici con analisi approfondite e modelli predittivi per decisioni informate

Automatisation des Processus

Creo strumenti personalizzati che automatizzano operazioni ripetitive e liberano tempo per attività a valore aggiunto

Systèmes Sur Mesure

Sviluppo sistemi software su misura, dalle integrazioni tra piattaforme alle dashboard personalizzate

const federico = {
  nome: "Federico Calò",
  ruolo: "Sviluppatore Software",
  città: "Bari, Italia",
  missione: "Aiutare attraverso l'informatica",
  passioni: [
    "Codice Pulito",
    "Innovazione",
    "Crescita Continua"
  ]
};

Ma Mission

Credo fermamente che l'informatica sia lo strumento più potente per trasformare le idee in realtà e migliorare la vita delle persone.

🚀

Démocratiser la Technologie

La mia missione è rendere l'informatica accessibile a tutti: dalle piccole imprese locali alle startup innovative, fino ai professionisti che vogliono digitalizzare la propria attività. Ogni realtà merita di sfruttare le potenzialità del digitale.

💡

Unir Informatique et Économie

Non è solo questione di scrivere codice: è capire come la tecnologia possa generare valore reale. Intrecciando competenze informatiche e visione economica, aiuto le attività a crescere, ottimizzare processi e raggiungere nuovi traguardi di efficienza e redditività.

🎯

Créer des Solutions Sur Mesure

Ogni attività è unica, e così devono esserlo le soluzioni. Sviluppo strumenti personalizzati che rispondono alle esigenze specifiche di ciascun cliente, automatizzando processi ripetitivi e liberando tempo per ciò che conta davvero: far crescere il business.

Transformez Votre Activité avec la Technologie

Dicembre 2024

Visualizza

Master SQL

RoadMap.sh

Novembre 2024

Visualizza

Oracle Certified Foundations Associate

Oracle

Ottobre 2024

Visualizza

People Leadership Credential

Connect

Settembre 2024

💻 Linguaggi & Tecnologie

☕Java

🐍Python

📜JavaScript

🅰️Angular

⚛️React

🔷TypeScript

🗄️SQL

🐘PHP

🎨CSS/SCSS

🔧Node.js

🐳Docker

🌿Git

💼

12/2024 - Presente

Custom Software Engineering Analyst

Accenture

Bari, Puglia, Italia · Ibrida Analisi e sviluppo di sistemi informatici attraverso l'utilizzo di Java e Quarkus in Health and Public Sector. Formazione continua su tecnologie moderne per la creazione di soluzioni software personalizzate ed efficienti e sugli agenti.

💼

06/2022 - 12/2024

Analista software e Back End Developer Associate Consultant

Links Management and Technology SpA

Esperienza nell'analisi di sistemi software as-is e flussi ETL utilizzando PowerCenter. Formazione completata su Spring Boot per lo sviluppo di applicazioni backend moderne e scalabili. Sviluppatore Backend specializzato in Spring Boot, con esperienza in progettazione di database, analisi, sviluppo e testing dei task assegnati.

💼

02/2021 - 10/2021

Programmatore software

Adesso.it (prima era WebScience srl)

Esperienza nell'analisi AS-IS e TO-BE, evoluzioni SEO ed evoluzioni website per migliorare le performance e l'engagement degli utenti.

🎓

2018 - 2025

Laurea in Informatica

Università degli Studi di Bari Aldo Moro

Bachelor's degree in Computer Science, focusing on software engineering, algorithms, and modern development practices.

📚

2013 - 2018

Diploma - Sistemi Informativi Aziendali

Istituto Tecnico Commerciale di Maglie

Technical diploma specializing in Business Information Systems, combining IT knowledge with business management.

Contactez-moi

Vous avez un projet en tête ? Parlons-en ! Remplissez le formulaire ci-dessous et je vous répondrai rapidement.

* Campi obbligatori. I tuoi dati saranno utilizzati solo per rispondere alla tua richiesta.

Introduction : CI/CD pour Développeurs Frontend

Tout développeur frontend est tôt ou tard confronté à la même question : comment puis-je automatiser le processus de build, test et déploiement de mon application ? La réponse moderne s'appelle CI/CD (Intégration Continue / Déploiement Continu), et GitHub Actions représente aujourd'hui l'outil le plus accessible et puissant pour l'implémenter directement dans le dépôt du projet.

Dans ce premier article de la série DevOps pour Développeurs Frontend, nous construirons de zéro un pipeline complet pour une application Angular : du premier workflow d'intégration continue jusqu'au déploiement automatique en production. Chaque concept est expliqué avec des exemples pratiques et du code prêt à l'emploi.

Ce Que Vous Apprendrez dans Cet Article

Les concepts fondamentaux de GitHub Actions : workflow, job, step et trigger
Comment configurer un workflow CI pour Angular (install, lint, test, build)
Comment implémenter le déploiement automatique sur Firebase et Vercel
Stratégies de mise en cache pour accélérer les pipelines
Matrix strategy pour tester sur plusieurs versions de Node.js
Comment configurer les artifacts et les branch protection rules
Comment créer des workflows réutilisables

1. Concepts Fondamentaux de GitHub Actions

GitHub Actions est une plateforme d'automatisation intégrée à GitHub. Chaque automatisation repose sur quatre concepts clés formant une hiérarchie précise :

      Hiérarchie de GitHub Actions
      
          Concept
          Description
          Analogie
        
          Workflow
          Un fichier YAML dans .github/workflows/ qui définit toute l'automatisation
          La recette complète
        
          Job
          Un groupe de steps exécuté sur un runner spécifique
          Une étape de la recette
        
          Step
          Une commande ou action individuelle au sein d'un job
          Une instruction spécifique
        
          Trigger
          L'événement qui déclenche le workflow (push, PR, schedule, etc.)
          Le moment de commencer

Un workflow peut contenir plusieurs jobs, et chaque job peut contenir plusieurs steps. Les jobs s'exécutent en parallèle par défaut, mais peuvent être configurés avec des dépendances pour une exécution séquentielle.

Structure d'un Workflow YAML

Chaque workflow réside dans le répertoire .github/workflows/ du dépôt. Voici la structure de base d'un fichier workflow :


# .github/workflows/ci.yml
name: CI Pipeline

# Trigger : quand exécuter le workflow
on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

# Variables d'environnement globales
env:
  NODE_VERSION: '20'

# Les jobs à exécuter
jobs:
  build:
    # Runner : machine virtuelle où exécuter
    runs-on: ubuntu-latest

    # Steps du job
    steps:
      # Step 1 : Checkout du code
      - name: Checkout repository
        uses: actions/checkout@v4

      # Step 2 : Setup Node.js
      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: #123;{ env.NODE_VERSION }}

      # Step 3 : Installation des dépendances
      - name: Install dependencies
        run: npm ci

      # Step 4 : Build
      - name: Build application
        run: npm run build

Les Triggers Principaux

Les triggers déterminent quand un workflow est déclenché. GitHub Actions supporte des dizaines d'événements, mais pour les projets frontend les plus utilisés sont :


on:
  # Sur chaque push aux branches spécifiées
  push:
    branches: [main, develop]
    paths:
      - 'src/**'
      - 'package.json'

  # Sur chaque Pull Request vers main
  pull_request:
    branches: [main]
    types: [opened, synchronize, reopened]

  # Exécution programmée (cron)
  schedule:
    - cron: '0 6 * * 1'  # Chaque lundi à 6h00 UTC

  # Trigger manuel
  workflow_dispatch:
    inputs:
      environment:
        description: 'Target environment'
        required: true
        default: 'staging'
        type: choice
        options:
          - staging
          - production

Attention aux Triggers sur Push

Le filtre paths est très utile pour éviter les builds inutiles : si vous ne modifiez que le README, il n'y a pas de raison de relancer tout le pipeline. Cependant, attention à ne pas exclure des fichiers critiques comme angular.json ou tsconfig.json qui influencent le build.

2. Workflow CI Complet pour Angular

Construisons maintenant un workflow d'Intégration Continue complet pour un projet Angular. Ce workflow exécutera en séquence : installation des dépendances, linting, tests unitaires et build de production.


# .github/workflows/ci.yml
name: Angular CI

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

env:
  NODE_VERSION: '20'

jobs:
  lint:
    name: Lint Check
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: #123;{ env.NODE_VERSION }}
          cache: 'npm'
      - run: npm ci
      - run: npx ng lint

  test:
    name: Unit Tests
    runs-on: ubuntu-latest
    needs: lint
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: #123;{ env.NODE_VERSION }}
          cache: 'npm'
      - run: npm ci
      - run: npx ng test --watch=false --browsers=ChromeHeadless --code-coverage
      - name: Upload coverage report
        uses: actions/upload-artifact@v4
        with:
          name: coverage-report
          path: coverage/
          retention-days: 7

  build:
    name: Production Build
    runs-on: ubuntu-latest
    needs: test
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: #123;{ env.NODE_VERSION }}
          cache: 'npm'
      - run: npm ci
      - run: npx ng build --configuration=production
      - name: Upload build artifacts
        uses: actions/upload-artifact@v4
        with:
          name: dist
          path: dist/
          retention-days: 3

Ce workflow définit trois jobs en séquence grâce au mot-clé needs : d'abord le lint, puis les tests, enfin le build. Si le lint échoue, les tests ne sont pas exécutés ; si les tests échouent, le build ne démarre pas.

Mise en Cache Avancée des Dépendances

Le mot-clé cache: 'npm' dans l'action setup-node fournit un cache de base. Pour un contrôle plus granulaire, nous pouvons utiliser directement l'action actions/cache :


  - name: Cache node_modules
    id: cache-npm
    uses: actions/cache@v4
    with:
      path: |
        node_modules
        ~/.npm
      key: #123;{ runner.os }}-npm-#123;{ hashFiles('package-lock.json') }}
      restore-keys: |
        #123;{ runner.os }}-npm-

  - name: Install dependencies
    if: steps.cache-npm.outputs.cache-hit != 'true'
    run: npm ci

La clé de cache utilise le hash du fichier package-lock.json : quand les dépendances ne changent pas, le cache est réutilisé et l'installation est complètement ignorée. Cela peut réduire le temps du pipeline de 30 à 60 secondes par exécution.

3. Matrix Strategy : Tests Multi-Versions

La matrix strategy permet d'exécuter le même job avec différentes combinaisons de paramètres. Pour un projet Angular, c'est particulièrement utile pour tester sur plusieurs versions de Node.js :


  test-matrix:
    name: Test on Node #123;{ matrix.node-version }}
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: [18, 20, 22]
      fail-fast: false
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: #123;{ matrix.node-version }}
          cache: 'npm'
      - run: npm ci
      - run: npx ng test --watch=false --browsers=ChromeHeadless

L'option fail-fast: false garantit que tous les jobs de la matrice se terminent même si l'un échoue, permettant d'identifier toutes les incompatibilités en une seule exécution.

Quand Utiliser la Matrix Strategy

Tests sur plusieurs versions de Node.js (LTS actuelle et précédente)
Tests sur plusieurs systèmes d'exploitation (ubuntu, windows, macos)
Build pour différents environnements (staging, production)
Tests avec différentes versions de navigateurs

4. CD : Déploiement Automatique sur Firebase

Après avoir construit et testé l'application, l'étape suivante est le déploiement automatique. Voyons comment configurer le déploiement sur Firebase Hosting, l'un des choix les plus courants pour les applications Angular.


# .github/workflows/deploy.yml
name: Deploy to Firebase

on:
  push:
    branches: [main]

jobs:
  build-and-deploy:
    name: Build and Deploy to Production
    runs-on: ubuntu-latest
    environment: production
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'

      - name: Install dependencies
        run: npm ci

      - name: Build for production
        run: npm run build

      - name: Deploy to Firebase Hosting
        uses: FirebaseExtended/action-hosting-deploy@v0
        with:
          repoToken: #123;{ secrets.GITHUB_TOKEN }}
          firebaseServiceAccount: #123;{ secrets.FIREBASE_SERVICE_ACCOUNT }}
          channelId: live
          projectId: my-angular-project

Preview Deploy pour les Pull Requests

Une fonctionnalité puissante de Firebase Hosting est la possibilité de créer des preview channels automatiques pour chaque Pull Request, permettant à l'équipe de vérifier les modifications avant le merge :


# .github/workflows/preview.yml
name: Deploy Preview

on:
  pull_request:
    branches: [main]

jobs:
  preview:
    name: Deploy Preview Channel
    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 build

      - name: Deploy to Preview Channel
        uses: FirebaseExtended/action-hosting-deploy@v0
        with:
          repoToken: #123;{ secrets.GITHUB_TOKEN }}
          firebaseServiceAccount: #123;{ secrets.FIREBASE_SERVICE_ACCOUNT }}
          projectId: my-angular-project

Déploiement sur Vercel

Pour ceux qui préfèrent Vercel comme plateforme d'hébergement, la configuration est tout aussi simple :


# .github/workflows/deploy-vercel.yml
name: Deploy to Vercel

on:
  push:
    branches: [main]

env:
  VERCEL_ORG_ID: #123;{ secrets.VERCEL_ORG_ID }}
  VERCEL_PROJECT_ID: #123;{ secrets.VERCEL_PROJECT_ID }}

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Install Vercel CLI
        run: npm install -g vercel

      - name: Pull Vercel Configuration
        run: vercel pull --yes --environment=production --token=#123;{ secrets.VERCEL_TOKEN }}

      - name: Build with Vercel
        run: vercel build --prod --token=#123;{ secrets.VERCEL_TOKEN }}

      - name: Deploy to Vercel
        run: vercel deploy --prebuilt --prod --token=#123;{ secrets.VERCEL_TOKEN }}

5. Artifacts : Partager des Fichiers entre Jobs

Les artifacts permettent de partager des fichiers entre différents jobs du même workflow. C'est fondamental pour séparer le build du déploiement sans recompiler :


jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
      - run: npm ci
      - run: npx ng build --configuration=production

      - name: Upload build artifact
        uses: actions/upload-artifact@v4
        with:
          name: angular-dist
          path: dist/my-app/browser/
          retention-days: 1

  deploy:
    runs-on: ubuntu-latest
    needs: build
    steps:
      - name: Download build artifact
        uses: actions/download-artifact@v4
        with:
          name: angular-dist
          path: dist/

      - name: Deploy
        run: |
          # Le contenu du build est maintenant dans dist/
          ls -la dist/

      Bonnes Pratiques pour les Artifacts
      Configurez toujours retention-days pour ne pas gaspiller l'espace de stockage
Utilisez des noms descriptifs pour les artifacts (angular-dist, coverage-report)
Téléchargez uniquement les fichiers nécessaires, pas tout le répertoire node_modules
Pour les fichiers très volumineux, envisagez la compression avant l'upload

    

6. Branch Protection Rules

Les branch protection rules de GitHub permettent d'imposer des contraintes sur les branches critiques. Combinées aux workflows CI, elles créent une barrière de qualité automatique.

Pour configurer les branch protection rules, allez dans Settings > Branches > Add branch protection rule dans votre dépôt GitHub. Les paramètres recommandés pour la branche main sont :

Require a pull request before merging : Empêche les push directs sur main
Require status checks to pass before merging : Les workflows CI doivent réussir
Require branches to be up to date before merging : La branche doit être à jour
Require conversation resolution before merging : Tous les commentaires doivent être résolus

Pour sélectionner quels status checks exiger, vous devez d'abord exécuter le workflow au moins une fois. Ensuite, les noms des jobs apparaîtront dans la liste de sélection :


Status checks requis :
  [x] Lint Check          (du workflow CI)
  [x] Unit Tests          (du workflow CI)
  [x] Production Build    (du workflow CI)

7. Workflows Réutilisables

Lorsqu'on gère plusieurs dépôts avec des configurations similaires, les reusable workflows évitent la duplication du code. Un workflow réutilisable est défini avec le trigger workflow_call :


# .github/workflows/reusable-angular-ci.yml
name: Reusable Angular CI

on:
  workflow_call:
    inputs:
      node-version:
        description: 'Node.js version'
        required: false
        default: '20'
        type: string
      build-command:
        description: 'Build command to execute'
        required: false
        default: 'npm run build'
        type: string
    secrets:
      FIREBASE_SA:
        description: 'Firebase Service Account'
        required: false

jobs:
  ci:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: #123;{ inputs.node-version }}
          cache: 'npm'
      - run: npm ci
      - run: npx ng lint
      - run: npx ng test --watch=false --browsers=ChromeHeadless
      - run: #123;{ inputs.build-command }}

Pour utiliser ce workflow réutilisable depuis un autre workflow :


# .github/workflows/ci.yml (dans le dépôt qui le consomme)
name: CI

on:
  push:
    branches: [main]

jobs:
  angular-ci:
    uses: my-org/shared-workflows/.github/workflows/reusable-angular-ci.yml@main
    with:
      node-version: '20'
      build-command: 'npm run build -- --configuration=production'
    secrets:
      FIREBASE_SA: #123;{ secrets.FIREBASE_SERVICE_ACCOUNT }}

Avantages des Workflows Réutilisables

DRY : Un seul point de maintenance pour la logique CI/CD
Standardisation : Tous les dépôts suivent les mêmes pratiques
Versionnement : Vous pouvez référencer une version spécifique du workflow (@main, @v1)
Sécurité : Les secrets sont passés explicitement, non partagés globalement

8. Exemple Complet : Pipeline End-to-End

Combinons tous les concepts dans un pipeline complet gérant CI et CD avec branch protection :


# .github/workflows/pipeline.yml
name: Full Pipeline

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

concurrency:
  group: #123;{ github.workflow }}-#123;{ github.ref }}
  cancel-in-progress: true

env:
  NODE_VERSION: '20'

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: #123;{ env.NODE_VERSION }}
          cache: 'npm'
      - run: npm ci
      - run: npx ng lint

  test:
    runs-on: ubuntu-latest
    needs: lint
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: #123;{ env.NODE_VERSION }}
          cache: 'npm'
      - run: npm ci
      - run: npx ng test --watch=false --browsers=ChromeHeadless --code-coverage
      - uses: actions/upload-artifact@v4
        with:
          name: coverage
          path: coverage/

  build:
    runs-on: ubuntu-latest
    needs: test
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: #123;{ env.NODE_VERSION }}
          cache: 'npm'
      - run: npm ci
      - run: npx ng build --configuration=production
      - uses: actions/upload-artifact@v4
        with:
          name: dist
          path: dist/

  deploy-preview:
    if: github.event_name == 'pull_request'
    runs-on: ubuntu-latest
    needs: build
    steps:
      - uses: actions/checkout@v4
      - uses: actions/download-artifact@v4
        with:
          name: dist
          path: dist/
      - uses: FirebaseExtended/action-hosting-deploy@v0
        with:
          repoToken: #123;{ secrets.GITHUB_TOKEN }}
          firebaseServiceAccount: #123;{ secrets.FIREBASE_SERVICE_ACCOUNT }}
          projectId: my-angular-project

  deploy-production:
    if: github.ref == 'refs/heads/main' && github.event_name == 'push'
    runs-on: ubuntu-latest
    needs: build
    environment: production
    steps:
      - uses: actions/checkout@v4
      - uses: actions/download-artifact@v4
        with:
          name: dist
          path: dist/
      - uses: FirebaseExtended/action-hosting-deploy@v0
        with:
          repoToken: #123;{ secrets.GITHUB_TOKEN }}
          firebaseServiceAccount: #123;{ secrets.FIREBASE_SERVICE_ACCOUNT }}
          channelId: live
          projectId: my-angular-project

L'option concurrency en haut du workflow est cruciale : si vous faites plusieurs push rapprochés sur la même branche, le workflow précédent est automatiquement annulé, économisant des minutes d'exécution.

9. Débogage et Bonnes Pratiques

Quand un workflow échoue, le débogage peut être frustrant. Voici les stratégies les plus efficaces :

Activer le Debug Logging

Vous pouvez activer les logs de debug en ajoutant des secrets au dépôt :

ACTIONS_RUNNER_DEBUG = true pour des logs détaillés du runner
ACTIONS_STEP_DEBUG = true pour des logs détaillés de chaque step

Steps Conditionnels pour le Debug


  - name: Debug info
    if: failure()
    run: |
      echo "Node version: $(node -v)"
      echo "NPM version: $(npm -v)"
      echo "Directory: $(pwd)"
      ls -la
      cat package.json

      Bonnes Pratiques pour GitHub Actions
      Utilisez npm ci au lieu de npm install pour des installations déterministes
Fixez toujours les versions des actions (@v4 au lieu de @main)
Configurez concurrency pour éviter les builds en double
Utilisez le cache pour réduire les temps d'exécution
Séparez les jobs pour un feedback rapide (le lint échoue immédiatement, pas après le build)
Utilisez environment pour protéger les secrets de production
Configurez timeout-minutes pour éviter les jobs bloqués
Surveillez la consommation des minutes GitHub Actions dans le plan de votre compte

    

Conclusion

Dans cet article, nous avons construit un pipeline CI/CD complet pour une application Angular en utilisant GitHub Actions. Nous avons exploré les concepts fondamentaux (workflow, job, step, trigger), implémenté la mise en cache des dépendances, configuré la matrix strategy pour des tests multi-versions, et mis en place le déploiement automatique sur Firebase et Vercel.

La clé du succès avec les pipelines CI/CD est l'itération progressive : commencez par un workflow simple (lint + build), puis ajoutez les tests, et enfin le déploiement automatique. N'essayez pas de tout implémenter d'un coup.

Dans le prochain article de la série, nous explorerons Docker pour développeurs frontend, en apprenant à conteneuriser une application Angular avec un Dockerfile multi-stage et à gérer des environnements de développement avec Docker Compose.

Concept	Description	Analogie
Workflow	Un fichier YAML dans `.github/workflows/` qui définit toute l'automatisation	La recette complète
Job	Un groupe de steps exécuté sur un runner spécifique	Une étape de la recette
Step	Une commande ou action individuelle au sein d'un job	Une instruction spécifique
Trigger	L'événement qui déclenche le workflow (push, PR, schedule, etc.)	Le moment de commencer