CI/CD pour projets TypeScript : GitHub Actions de A à Z

Introduction : Pourquoi le CI/CD est crucial pour les projets TypeScript

Le développement en TypeScript est un outil puissant, mais sans automatisation des processus de build, de test et de déploiement, vous risquez de rencontrer des erreurs humaines, une perte de temps et une instabilité de la production. CI/CD (Intégration Continue / Déploiement Continu) est une philosophie et un ensemble de pratiques qui permettent d'automatiser ces processus. GitHub Actions est un outil intégré à GitHub, parfaitement adapté aux projets TypeScript, offrant des pipelines flexibles, évolutifs et gratuits (pour les dépôts publics).

Dans cet article, nous passerons de zéro à un pipeline complet : nous configurerons le linting, les tests, le build et le déploiement automatique d'une application TypeScript. Vous apprendrez à écrire des configurations YAML efficaces, à optimiser le temps d'exécution et à éviter les erreurs courantes.

Partie principale : Création pas à pas d'un pipeline CI/CD

1. Bases de GitHub Actions : structure d'un workflow

Un workflow (processus de travail) dans GitHub Actions est un ensemble d'étapes regroupées en jobs. Il est décrit dans un fichier YAML, stocké dans le répertoire .github/workflows/ de votre dépôt. La structure de base ressemble à ceci :

name: Pipeline CI/CD pour TypeScript\n\non:\n  push:\n    branches: [ main, develop ]\n  pull_request:\n    branches: [ main ]\n\njobs:\n  build-and-test:\n    runs-on: ubuntu-latest\n\n    steps:\n      - uses: actions/checkout@v4\n      - name: Configuration Node.js\n        uses: actions/setup-node@v4\n        with:\n          node-version: '20'\n          cache: 'npm'\n      - run: npm ci\n      - run: npm run build\n      - run: npm test

Éléments clés :

\n
• on: — déclencheurs (push, pull_request).
\n
• jobs: — liste des tâches (jobs) exécutées en parallèle ou séquentiellement.
\n
• runs-on: — système d'exploitation pour l'exécution (généralement ubuntu-latest).
\n
• steps: — séquence de commandes. uses appelle des actions prêtes à l'emploi, et run exécute des commandes shell.
\n
• npm ci — installation rapide et propre des dépendances à partir de package-lock.json.
\n

Ce pipeline minimal fournit déjà une CI de base : à chaque push ou PR, le code sera vérifié pour le build et les tests.

2. Configuration avancée : linting, formatage et matrice de versions

Pour les projets TypeScript, il est essentiel de maintenir un style de code cohérent. Ajoutons une vérification avec un linter (eslint) et un formateur (prettier). Utilisons également une matrice de stratégies pour tester sur plusieurs versions de Node.js.

jobs:\n  lint-and-format:\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions/checkout@v4\n      - uses: actions/setup-node@v4\n        with:\n          node-version: '20'\n          cache: 'npm'\n      - run: npm ci\n      - run: npm run lint\n      - run: npm run format:check\n\n  test:\n    needs: lint-and-format\n    runs-on: ubuntu-latest\n    strategy:\n      matrix:\n        node-version: [18, 20, 22]\n    steps:\n      - uses: actions/checkout@v4\n      - uses: actions/setup-node@v4\n        with:\n          node-version: ${{ matrix.node-version }}\n          cache: 'npm'\n      - run: npm ci\n      - run: npm test

Points importants :

\n
• needs: — définit l'ordre d'exécution des jobs (d'abord le linting, puis les tests).
• strategy.matrix — permet d'exécuter le même job avec différents paramètres (versions de Node.js).
• La mise en cache (cache: 'npm') accélère l'installation des dépendances.
• Ajoutez dans package.json les scripts : "lint": "eslint src/" et "format:check": "prettier --check src/".

Maintenant, votre pipeline non seulement vérifie