GitHub Actions : automatiser le CI/CD des projets TypeScript

Chaque pull request devrait être validée automatiquement avant qu’un humain ne la review. Type checking, linting, tests et vérification du build devraient se lancer sur chaque push sans que personne ne les déclenche manuellement. GitHub Actions rend ça natif au dépôt. Les workflows sont des fichiers YAML committés avec le code, déclenchés par des événements git, et exécutés sur les runners GitHub. Pas de service CI externe à configurer, pas de webhooks à maintenir, pas de dashboard séparé à surveiller.

Un workflow CI complet pour TypeScript

Un seul fichier workflow peut lancer le type checking, le linting et les tests en parallèle. Chaque job tourne sur son propre runner, donc les échecs sont isolés et le temps total du pipeline équivaut au job le plus lent, pas à la somme de tous les jobs.

name: CI

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

jobs:
  typecheck:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: pnpm/action-setup@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: pnpm
      - run: pnpm install --frozen-lockfile
      - run: pnpm tsc --noEmit

  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: pnpm/action-setup@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: pnpm
      - run: pnpm install --frozen-lockfile
      - run: pnpm eslint . --max-warnings 0

  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: pnpm/action-setup@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: pnpm
      - run: pnpm install --frozen-lockfile
      - run: pnpm vitest run --coverage

L’option cache: pnpm sur setup-node met en cache le store pnpm entre les runs. Ça réduit les temps d’installation de plusieurs minutes à quelques secondes sur les exécutions suivantes. --frozen-lockfile garantit que la CI utilise les versions exactes des dépendances du lockfile, empêchant la dérive “ça marche sur ma machine”.

Workflows réutilisables pour éviter la duplication

Quand plusieurs dépôts partagent la même structure CI, copier les fichiers YAML entre eux crée un fardeau de maintenance. Les workflows réutilisables permettent de définir un workflow une fois et de l’appeler depuis n’importe quel dépôt.

name: Reusable CI

on:
  workflow_call:
    inputs:
      node-version:
        type: string
        default: '22'

jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: pnpm/action-setup@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ inputs.node-version }}
          cache: pnpm
      - run: pnpm install --frozen-lockfile
      - run: pnpm tsc --noEmit
      - run: pnpm eslint . --max-warnings 0
      - run: pnpm vitest run

name: CI
on: [push, pull_request]

jobs:
  ci:
    uses: your-org/shared-workflows/.github/workflows/ci-reusable.yml@main
    with:
      node-version: '22'

Le workflow appelant fait trois lignes. Toute la logique vit dans le dépôt partagé. Mettre à jour le pipeline CI pour tous les projets revient à modifier un seul fichier.

Automatiser les déploiements avec la protection d’environnements

GitHub Actions gère les pipelines de déploiement avec des règles de protection d’environnement intégrées. Les déploiements en production peuvent nécessiter une approbation manuelle, restreindre les branches autorisées à déployer, et stocker des secrets spécifiques à chaque environnement.

name: Deploy

on:
  push:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: pnpm/action-setup@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: pnpm
      - run: pnpm install --frozen-lockfile
      - run: pnpm build
      - uses: actions/upload-artifact@v4
        with:
          name: build-output
          path: .next/

  deploy:
    needs: build
    runs-on: ubuntu-latest
    environment: production
    steps:
      - uses: actions/download-artifact@v4
        with:
          name: build-output
          path: .next/
      - run: echo "Deploying to production..."

La déclaration environment: production se lie aux paramètres d’environnement GitHub où on configure les reviewers requis, les timers d’attente et les politiques de branches de déploiement. L’artefact de build est passé entre les jobs pour que le step de deploy utilise exactement ce qui a été testé.

Workflows planifiés et automatisation

Au-delà du CI/CD, GitHub Actions exécute des tâches planifiées directement dans le dépôt. Audits de dépendances, nettoyage d’issues inactives et health checks périodiques s’intègrent naturellement.

name: Security Audit

on:
  schedule:
    - cron: '0 8 * * 1'

jobs:
  audit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: pnpm/action-setup@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: pnpm
      - run: pnpm install --frozen-lockfile
      - run: pnpm audit --audit-level=high

Ça tourne tous les lundis à 8h. Si pnpm audit trouve des vulnérabilités de sévérité haute, le workflow échoue et GitHub envoie une notification. Pas de service cron externe, pas d’outil de monitoring séparé.

Conclusion

GitHub Actions transforme le dépôt en source unique de vérité pour le code et l’automatisation. Pipelines CI, workflows de déploiement, tâches planifiées et templates réutilisables vivent tous à côté du code sur lequel ils opèrent. Pour les projets TypeScript, la combinaison de jobs parallèles, de cache de dépendances et de protection d’environnements couvre tout le chemin du commit à la production.