CI/CD pour QA: GitHub Actions, Jenkins et GitLab Comparés

GitHub Actions, GitLab CI et Jenkins partagent le même objectif : exécuter vos tests à chaque changement de code. La syntaxe diffère. Le modèle mental est identique.

Ce que CI/CD signifie concrètement pour le QA

CI signifie Continuous Integration (intégration continue). Le principe : à chaque fois qu'un développeur pousse du code, un processus automatisé se lance, compile le code, exécute les tests, rapporte les résultats. Les problèmes sont détectés quelques minutes après leur introduction, pas des jours plus tard lors des tests manuels.

CD signifie Continuous Delivery (ou Deployment, livraison ou déploiement continu). Une fois que la CI passe, le code est automatiquement déployé sur un environnement de staging, voire en production.

Pour un ingénieur QA, la partie pertinente est la CI. Vos tests s'exécutent dans le pipeline. Chaque pull request les déclenche. Si les tests échouent, la PR ne peut pas être mergée. C'est le contrat.

Des tests qui ne s'exécutent que sur votre machine n'imposent rien. Des tests en CI imposent le niveau de qualité à chaque changement, automatiquement.

GitHub Actions : commencez ici

GitHub Actions est l'outil CI le plus facile à apprendre et le plus utilisé pour les nouveaux projets. Il est gratuit pour les dépôts publics et dispose d'un tier gratuit généreux pour les dépôts privés.

Le concept : vous définissez un workflow dans un fichier YAML à l'intérieur de votre dépôt. GitHub exécute ce workflow à chaque fois qu'un événement déclencheur se produit, comme un push, une pull request ou une planification.

Créez .github/workflows/playwright.yml à la racine de votre projet :

mkdir -p .github/workflows

# .github/workflows/playwright.yml
name: Playwright Tests

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

jobs:
  test:
    runs-on: ubuntu-latest

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

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

      - name: Install dependencies
        run: npm ci

      - name: Install Playwright browsers
        run: npx playwright install --with-deps

      - name: Run Playwright tests
        run: npx playwright test

      - name: Upload test report
        uses: actions/upload-artifact@v4
        if: always()
        with:
          name: playwright-report
          path: playwright-report/
          retention-days: 14

Committez ce fichier, poussez vers GitHub, et ouvrez l'onglet Actions. Vous verrez le workflow s'exécuter. Il installe Node, installe les navigateurs Playwright, lance vos tests, et uploade le rapport HTML comme artifact téléchargeable.

Le if: always() sur l'étape d'upload signifie que le rapport est uploadé même quand les tests échouent, ce qui est exactement le moment où vous en avez le plus besoin.

Comprendre le fichier de workflow

Variables d'environnement dans GitHub Actions

Ne codez jamais les identifiants en dur dans le fichier de workflow. Stockez-les comme GitHub Secrets et référencez-les comme variables d'environnement.

Allez dans votre dépôt → Settings → Secrets and variables → Actions → New repository secret. Ajoutez TEST_USER et TEST_PASS.

Référencez-les dans le workflow :

      - name: Run Playwright tests
        run: npx playwright test
        env:
          TEST_USER: ${{ secrets.TEST_USER }}
          TEST_PASS: ${{ secrets.TEST_PASS }}
          BASE_URL: https://lab.becomeqa.com

Dans vos tests, accédez-y via process.env.TEST_USER. Les secrets sont masqués dans les logs. GitHub remplace leurs valeurs par * s'ils apparaissent dans la sortie.

Accélérer les tests avec le sharding

Par défaut, Playwright utilise plusieurs workers sur une seule machine. Pour les suites importantes, vous pouvez répartir sur plusieurs machines avec le sharding.

jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        shard: [1, 2, 3, 4]

    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: 'npm'
      - run: npm ci
      - run: npx playwright install --with-deps
      - run: npx playwright test --shard=${{ matrix.shard }}/4

Cela exécute 4 jobs en parallèle, chacun gérant 25% des tests. Une suite qui prend 20 minutes sur une machine prend 5 minutes répartie sur quatre.

GitLab CI

GitLab CI utilise les mêmes concepts que GitHub Actions mais une syntaxe différente. Le fichier de configuration est .gitlab-ci.yml à la racine du projet.

# .gitlab-ci.yml
image: mcr.microsoft.com/playwright:v1.44.0-jammy

stages:
  - test

playwright:
  stage: test
  script:
    - npm ci
    - npx playwright test
  artifacts:
    when: always
    paths:
      - playwright-report/
    expire_in: 1 week
  variables:
    TEST_USER: $TEST_USER
    TEST_PASS: $TEST_PASS

Différences clés par rapport à GitHub Actions :

Le champ image: spécifie une image Docker pour le job. Utiliser l'image Playwright officielle (mcr.microsoft.com/playwright) signifie que les navigateurs sont déjà installés, donc npx playwright install n'est pas nécessaire.

Les variables sont définies dans GitLab → Project → Settings → CI/CD → Variables. Référencez-les avec $NOM_VARIABLE dans la configuration.

Si vous connaissez GitHub Actions, vous pouvez assimiler GitLab CI en une journée. Le modèle mental est identique : déclencheurs, jobs, étapes, artifacts. Juste un YAML différent.

Jenkins

Jenkins est plus ancien, plus complexe, et toujours dominant dans les grands environnements enterprise. Vous le rencontrerez dans des entreprises avec une infrastructure legacy.

Jenkins utilise un Jenkinsfile à la racine du projet :

pipeline {
  agent {
    docker {
      image 'mcr.microsoft.com/playwright:v1.44.0-jammy'
    }
  }

  environment {
    TEST_USER = credentials('test-user')
    TEST_PASS = credentials('test-pass')
  }

  stages {
    stage('Install') {
      steps {
        sh 'npm ci'
      }
    }

    stage('Test') {
      steps {
        sh 'npx playwright test'
      }
      post {
        always {
          publishHTML(target: [
            reportDir: 'playwright-report',
            reportFiles: 'index.html',
            reportName: 'Playwright Report'
          ])
        }
      }
    }
  }
}

Jenkins nécessite un serveur Jenkins en fonctionnement. Ce n'est pas un service cloud. Quelqu'un doit l'installer, le configurer et le maintenir. C'est pourquoi GitHub Actions l'a largement remplacé pour les nouveaux projets.

Pour le QA spécifiquement : si vous rejoignez une entreprise utilisant Jenkins, vous n'avez pas besoin de comprendre l'administration Jenkins. Vous devez comprendre la syntaxe du Jenkinsfile suffisamment pour ajouter ou modifier des stages de test. Le pipeline DSL (la syntaxe ci-dessus) est ce avec quoi les ingénieurs QA travaillent au quotidien.

Quel outil apprendre en premier

Le choix est simple.

À quoi ressemble un vrai pipeline CI

Un pipeline Playwright mature dans un projet réel a généralement plus que simplement "lancer les tests" :

# Pipeline de production réaliste
jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npx tsc --noEmit        # Vérification des types TypeScript
      - run: npx eslint tests/       # Lint des fichiers de test

  test:
    needs: lint
    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 playwright install --with-deps
      - run: npx playwright test --project=chromium  # retour rapide sur un navigateur
        env:
          BASE_URL: ${{ vars.BASE_URL }}
          TEST_USER: ${{ secrets.TEST_USER }}
          TEST_PASS: ${{ secrets.TEST_PASS }}
      - uses: actions/upload-artifact@v4
        if: always()
        with:
          name: playwright-report
          path: playwright-report/

  test-cross-browser:
    needs: test
    if: github.ref == 'refs/heads/main'  # uniquement sur la branche main
    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 playwright install --with-deps
      - run: npx playwright test  # tous les navigateurs

Le pattern : retour rapide d'abord (lint + Chromium), puis cross-browser complet sur la branche main. Les pull requests obtiennent des résultats rapides ; les merges obtiennent une couverture complète.

FAQ

Vérifiez trois choses : les variables d'environnement (secrets non configurés dans Actions), l'URL de base (localhost codé en dur qui n'existe pas en CI), et le timing. Les runners CI sont plus lents que votre machine locale, donc ajoutez retries: 1 dans playwright.config.ts pour la CI.

Dans GitHub Actions : allez sur le run échoué → Summary → Artifacts → téléchargez playwright-report. Extrayez le zip et ouvrez index.html dans un navigateur.

Pas nativement dans Playwright. Certaines équipes utilisent un filtrage par chemin : exécuter uniquement les tests dans tests/auth/ quand des fichiers dans src/auth/ ont changé. C'est complexe à mettre en place de façon fiable. Commencez par lancer la suite complète et optimisez plus tard si elle devient trop lente.

Ajoutez un déclencheur planifié :

on:
  schedule:
    - cron: '0 2 * * *'   # 2h UTC chaque nuit
  push:
    branches: [main]

Les runs nocturnes sont utiles pour détecter les échecs intermittents qui n'apparaissent pas à chaque run de PR.