Retour aux articles
DevOps10 min de lecture

Construire des pipelines CI/CD avec GitHub Actions

Un guide complet pour créer des pipelines de déploiement production-grade avec tests automatisés, scan de sécurité et déploiements multi-stages.

2024-09-10

Construire des pipelines CI/CD avec GitHub Actions

GitHub Actions est devenu ma plateforme CI/CD de prédilection pour la plupart des projets. Il est profondément intégré à GitHub, dispose d'un marketplace extensif d'actions, et la syntaxe YAML est intuitive une fois les concepts fondamentaux maîtrisés.

Un workflow production-grade

Voici la structure de workflow que j'utilise pour déployer des applications conteneurisées sur AKS :

name: Deploy to Production

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

env:
  REGISTRY: myregistry.azurecr.io
  IMAGE_NAME: web-api

jobs:
  test:
    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 -- --coverage
      - uses: actions/upload-artifact@v4
        with:
          name: coverage
          path: coverage/

  security-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run Trivy vulnerability scanner
        uses: aquasecurity/trivy-action@master
        with:
          scan-type: 'fs'
          format: 'sarif'
          output: 'trivy-results.sarif'
          severity: 'CRITICAL,HIGH'
      - uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: 'trivy-results.sarif'

  build-and-push:
    needs: [test, security-scan]
    if: github.event_name == 'push' && github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: azure/login@v2
        with:
          creds: ${{ secrets.AZURE_CREDENTIALS }}
      - run: az acr login --name myregistry
      - name: Build and push
        run: |
          docker build -t $REGISTRY/$IMAGE_NAME:${{ github.sha }} .
          docker push $REGISTRY/$IMAGE_NAME:${{ github.sha }}

  deploy:
    needs: build-and-push
    runs-on: ubuntu-latest
    environment: production
    steps:
      - uses: actions/checkout@v4
      - uses: azure/login@v2
        with:
          creds: ${{ secrets.AZURE_CREDENTIALS }}
      - uses: azure/aks-set-context@v4
        with:
          resource-group: rg-prod
          cluster-name: aks-prod
      - run: |
          kubectl set image deployment/web-api \
            api=$REGISTRY/$IMAGE_NAME:${{ github.sha }}
          kubectl rollout status deployment/web-api --timeout=300s

Décisions de conception clés

Jobs parallèles pour la rapidité : Les jobs test et security-scan s'exécutent en parallèle puisqu'ils ne dépendent pas l'un de l'autre. Le job build-and-push attend que les deux réussissent avant de continuer.

Règles de protection d'environnement : Le job deploy cible l'environnement production, qui peut être configuré dans GitHub avec des reviewers obligatoires, des délais d'attente et des restrictions de branches.

Tagging d'images avec le SHA : Utiliser le SHA Git comme tag d'image crée un lien immuable et traçable entre le conteneur déployé et le commit exact du code.

Gestion des secrets

Ne codez jamais les credentials en dur. Utilisez les secrets chiffrés de GitHub et, pour Azure, préférez l'authentification basée sur OIDC aux secrets de service principal :

permissions:
  id-token: write
  contents: read

steps:
  - uses: azure/login@v2
    with:
      client-id: ${{ secrets.AZURE_CLIENT_ID }}
      tenant-id: ${{ secrets.AZURE_TENANT_ID }}
      subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

L'OIDC élimine le besoin de rotation des secrets et réduit le rayon d'impact d'un workflow compromis.

Workflows réutilisables

Pour les organisations avec plusieurs dépôts, extrayez les patterns communs dans des workflows réutilisables :

# .github/workflows/reusable-deploy.yml
on:
  workflow_call:
    inputs:
      environment:
        required: true
        type: string
      image-tag:
        required: true
        type: string
    secrets:
      AZURE_CREDENTIALS:
        required: true

Cela garde votre CI/CD DRY et assure des pratiques de déploiement cohérentes à travers tous les projets.

Monitoring des déploiements

Après le déploiement, j'ajoute toujours une étape de notification — que ce soit un message Slack, un webhook Teams, ou une annotation dans Grafana. Savoir exactement quand un déploiement a eu lieu est inestimable pour corréler les changements de métriques avec les changements de code.

Un pipeline CI/CD bien conçu est l'épine dorsale d'une livraison logicielle fiable. Investissez du temps pour le mettre au point, et il vous fera gagner du temps chaque jour.

Partager cet article

LinkedInTwitter

Besoin d'aide pour votre infrastructure ?

Discutons de votre projet et trouvons la meilleure solution ensemble.

Prendre contact