FR
RU
EN
ES
ZH
DE
PT
AR
HI
Pipeline CI/CD pour TypeScript : configuration de zéro — guide étape par étape
\n\nVous avez écrit un super projet en TypeScript. Le code est beau, les types sont stricts, la logique est vérifiée. Mais à chaque fois que vous devez mettre à jour le serveur, vous lancez manuellement le build, vérifiez que rien n'est cassé, et priez pour que la production ne plante pas. Cela vous dit quelque chose ?
\n\nIl est temps de changer cela. Un pipeline CI/CD n'est pas de la magie réservée aux seniors avec vingt ans d'expérience. C'est un outil qui automatise les tâches répétitives : linting, tests, build et déploiement. Un seul commit dans la branche, et tout part en production automatiquement, sans stress.
\n\nDans cet article, nous allons configurer de zéro un pipeline CI/CD complet pour un projet TypeScript. En utilisant GitHub Actions — un outil gratuit et puissant. Vous apprendrez à :
\n- \n
- Ajouter du linting et du formatage automatiques \n
- Lancer des tests unitaires et vérifier les types \n
- Compiler l'application et la déployer sur un serveur distant \n
- Éviter les erreurs courantes lors de la configuration CI/CD \n
Prêt ? C'est parti !
\n\nPourquoi le CI/CD est crucial pour un projet TypeScript
\n\nTypeScript est un langage fortement typé qui se compile en JavaScript. À première vue, cela donne une illusion de sécurité : si le code se compile, il fonctionne. Mais en pratique, la compilation ne détecte pas les erreurs logiques, les problèmes d'API ou les dépendances tordues.
\n\nLe CI/CD (Intégration Continue / Déploiement Continu) résout ce problème :
\n- \n
- Vérification automatique : chaque commit passe par le pipeline — linting, tests, compilation. Si quelque chose casse, vous le savez en une minute, pas en une semaine. \n
- Standard unique : toute l'équipe travaille selon les mêmes règles. Personne n'oublie de lancer les tests avant de pusher. \n
- Déploiement rapide : plus de commandes manuelles sur le serveur. Un seul merge dans main, et la mise à jour est déjà sur le site en production. \n
Pour TypeScript, le CI/CD est particulièrement important car les erreurs de type peuvent n'apparaître qu'à l'exécution si la compilation n'est pas correctement configurée. Le pipeline les empêche.
\n\nÉtape 1 : Préparation du projet TypeScript
\n\nAvant de configurer le CI/CD, assurez-vous que le projet est prêt pour l'automatisation. Voici le minimum requis :
\n- \n
package.jsonavec les scripts définis \n tsconfig.json— la configuration TypeScript \n - ESLint et Prettier — pour l'uniformité du code \n
- Des tests (Jest, Vitest ou Mocha) \n
Supposons que vous ayez un projet simple. La structure pourrait ressembler à ceci :
\n\nmy-ts-project/\n├── src/\n│ ├── index.ts\n│ └── utils.ts\n├── tests/\n│ └── utils.test.ts\n├── .eslintrc.json\n├── .prettierrc\n├── tsconfig.json\n├── package.json\n└── README.md\nAssurez-vous que les scripts sont définis dans package.json :
{\n "scripts": {\n "lint": "eslint src/ tests/ --ext .ts",\n "format": "prettier --check src/ tests/",\n "type-check": "tsc --noEmit",\n "test": "jest",\n "build": "tsc",\n "start": "node dist/index.js"\n }\n}\nMaintenant, le projet est prêt pour le CI/CD. Si quelque chose manque, ajoutez-le. Le pipeline appellera exactement ces commandes.
\n\nÉtape 2 : Choix de la plateforme CI/CD
\n\nIl existe de nombreuses options : Jenkins, GitLab CI, CircleCI, Travis CI. Mais pour les débutants et les petits projets, GitHub Actions est le meilleur choix :
\n- \n
- Intégré à GitHub — pas besoin de configurer quoi que ce soit séparément \n
- Limite gratuite : 2000 minutes par mois (pour les dépôts privés) \n
- Énorme écosystème d'actions prêtes à l'emploi \n
- Syntaxe YAML claire \n
Si votre code est sur GitLab — utilisez GitLab CI (la description est presque identique). Mais dans cet article, nous travaillons avec GitHub.
\n\nÉtape 3 : Création du pipeline CI/CD — premier fichier
\n\nÀ la racine du projet, créez un dossier .github/workflows/, et à l'intérieur, un fichier ci.y
