FR
RU
EN
ES
ZH
DE
PT
AR
HI
Introduction : Pourquoi un CI/CD avancé pour TypeScript ?
Un pipeline CI/CD de base, qui se contente d'exécuter npm test et npm build, cesse d'être efficace dès que le projet TypeScript commence à grandir. Le temps de build augmente, les tests prennent des heures, et la gestion manuelle des versions entraîne des erreurs. Un niveau avancé de configuration de GitHub Actions permet de résoudre ces problèmes : accélérer le pipeline grâce à la mise en cache, exécuter les tests en parallèle pour différentes versions de Node.js et systèmes d'exploitation, et automatiser le déploiement en production.
Dans cet article, nous aborderons trois techniques clés pour les projets TypeScript : la mise en cache intelligente de node_modules, les builds matriciels pour vérifier la compatibilité, et le déploiement automatique avec actions/upload-pages-artifact. Tous les exemples sont écrits en TypeScript et prêts à être intégrés dans votre dépôt.
1. Mise en cache intelligente des dépendances et de la compilation
Le premier problème des grands projets TypeScript est le temps d'installation des dépendances et de compilation. GitHub Actions fournit un mécanisme de mise en cache, mais il faut le configurer correctement. Au lieu de mettre en cache tout le dossier node_modules (ce qui peut entraîner des versions obsolètes), il est préférable de mettre en cache package-lock.json et le dossier .cache du compilateur.
Exemple de mise en cache avancée pour TypeScript :
name: TypeScript CI (Advanced)on: [push, pull_request]
jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Setup Node.js uses: actions/setup-node@v4 with: node-version: '20' cache: 'npm' - name: Cache TypeScript cache uses: actions/cache@v4 with: path: | **/node_modules **/.tsbuildinfo key: ${{ runner.os }}-ts-${{ hashFiles('**/package-lock.json') }} restore-keys: | ${{ runner.os }}-ts- - run: npm ci - run: npm run build --if-present - run: npm testL'optimisation clé ici est l'utilisation de hashFiles('**/package-lock.json') pour générer une clé de cache unique. Si package-lock.json n'a pas changé, le cache est restauré en quelques secondes. Le flag --if-present permet d'ignorer le script de build s'il n'est pas défini.
2. Builds matriciels : tests sur différentes versions de Node.js et systèmes d'exploitation
TypeScript est compilé en JavaScript, mais le comportement du code peut différer selon les environnements d'exécution. La stratégie matricielle de GitHub Actions permet d'exécuter le même pipeline sur plusieurs combinaisons de systèmes d'exploitation et de versions de Node.js. C'est crucial pour les bibliothèques et les applications serveur.
Exemple de configuration matricielle pour un projet TypeScript :
jobs: test: runs-on: ${{ matrix.os }} strategy: matrix: os: [ubuntu-latest, windows-latest, macos-latest] node-version: [18, 20, 22] exclude: - os: windows-latest node-version: 22 fail-fast: false
steps: - uses: actions/checkout@v4 - name: Use Node.js ${{ matrix.node-version }} uses: actions/setup-node@v4 with: node-version: ${{ matrix.node-version }} cache: 'npm' - run: npm ci - run: npx tsc --noEmit - run: npm test - name: Upload coverage uses: actions/upload-artifact@v4 with: name: coverage-${{ matrix.os }}-${{ matrix.node-version }} path: coverage/Points clés :
fail-fast: false— n'arrête pas les autres jobs en cas d'erreur sur l'un d'eux. Permet de voir tous les problèmes en une seule fois.exclude— permet d'exclure les combinaisons connues pour être non fonctionnelles (par exemple, Node 22 sur Windows, s'il y a un problème connu).upload-artifact— télécharge les rapports de couverture de code pour chaque combinaison, ce qui permet une analyse détaillée.
3. Déploiement automatisé avec GitHub Pages et actions/upload-pages-artifact
Pour les projets TypeScript qui génèrent un site statique (par exemple, une documentation ou une application React), le déploiement sur GitHub Pages peut être entièrement automatisé. L'action actions/upload-pages-artifact prépare les fichiers de build pour le déploiement, et actions/deploy-pages effectue le déploiement proprement dit.
Exemple de workflow de déploiement :
name: Deploy to GitHub Pages
on: push: branches: [main]
jobs: deploy: runs-on: ubuntu-latest permissions: contents: read pages: write id-token: write
environment: name: github-pages url: ${{ steps.deployment.outputs.page_url }}
steps: - uses: actions/checkout@v4 - name: Setup Node.js uses: actions/setup-node@v4 with: node-version: '20' cache: 'npm' - run: npm ci - run: npm run build - name: Upload artifact uses: actions/upload-pages-artifact@v3 with: path: './dist' - name: Deploy to GitHub Pages id: deployment uses: actions/deploy-pages@v4Ce workflow ne se déclenche que lors d'un push sur la branche main. Il construit le projet, télécharge le dossier dist en tant qu'artefact, puis le déploie sur GitHub Pages. Les permissions pages: write et id-token: write sont nécessaires pour l'authentification.
Conclusion : Automatisation complète du pipeline TypeScript
La mise en place d'un pipeline CI/CD avancé pour TypeScript avec GitHub Actions permet non seulement de gagner du temps, mais aussi d'augmenter la fiabilité des livraisons. La mise en cache intelligente réduit le temps d'exécution des workflows de 40 à 60 %, les builds matriciels garantissent la compatibilité entre différentes versions de Node.js et systèmes d'exploitation, et le déploiement automatisé élimine les erreurs manuelles.
Pour approfondir, nous recommandons d'étudier la documentation officielle de GitHub Actions et d'expérimenter avec des workflows complexes dans des dépôts de test. L'intégration de ces techniques dans vos projets TypeScript vous permettra de vous concentrer sur le développement de fonctionnalités, en laissant l'automatisation gérer la qualité et la livraison.
