GitHub Actions s'est imposé comme l'outil natif des projets Angular hébergés sur GitHub. Contrairement aux solutions externes, vous n'avez pas besoin de compte tiers, de clés d'authentification distribuées ou de configuration baroque : tout vit dans votre repository. Pour un projet Angular moderne, cela signifie une chaîne complète de validation, de test et de déploiement, déclenchée automatiquement à chaque push ou pull request. L'avantage majeur est la transparence : chaque développeur voit exactement ce qui s'exécute, où et pourquoi. Les workflows sont versionnés avec votre code, ce qui élimine la dérive entre l'environnement local et la CI.
Architecture d'un workflow Angular efficace
Un pipeline bien pensé suit trois étapes majeures : validation statique, exécution des tests, puis build et déploiement. La validation commence par linter le code Angular avec ESLint, vérifier le formatage avec Prettier, et exécuter ng build en mode strict pour attraper les erreurs de typage TypeScript. Ensuite, vous lancez la suite de tests unitaires avec Karma et, optionnellement, les tests e2e avec Cypress ou Playwright. Enfin, vous générez le build optimisé avec ng build --prod, minifiez les assets, et poussez le résultat vers votre hébergement (Vercel, Netlify, AWS S3, etc.). Chaque étape doit échouer rapidement si un problème est détecté, sans attendre les suivantes. Cela réduit le temps de feedback et force à corriger les bugs au plus tôt.
Voici une structure minimale mais complète d'un fichier .github/workflows/ci-cd.yml :
name: CI/CD Angular
on:
push:
branches: [main, develop]
pull_request:
branches: [main]
jobs:
lint-and-test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: '20'
cache: 'npm'
- run: npm ci
- run: npm run lint
- run: npm run test -- --watch=false --browsers=ChromeHeadless
- run: npm run build -- --configuration production
deploy:
needs: lint-and-test
if: github.ref == 'refs/heads/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: npm run build -- --configuration production
- uses: actions/upload-artifact@v4
with:
name: angular-dist
path: dist/
- name: Deploy to Netlify
uses: nwtgck/actions-netlify@v2.0
with:
publish-dir: './dist/my-app'
github-token: ${{ secrets.GITHUB_TOKEN }}
deploy-message: 'Deploy from GitHub Actions'
alias: deploy-preview-${{ github.event.number }} Ce workflow exécute lint et tests en parallèle sur chaque push et PR. Seul le job deploy s'exécute si tous les tests passent ET si le push est sur la branche main . L'utilisation de cache: 'npm' accélère drastiquement les installations de dépendances.
Optimiser la vitesse du pipeline
La durée d'exécution d'un workflow est critique : plus elle est courte, plus rapide le feedback. Le cache npm est indispensable ; il réduit le temps d'installation de plusieurs minutes à quelques secondes sur les runs suivants. Utilisez également npm ci au lieu de npm install pour garantir des versions exactes et éviter les fluctuations. Pour les tests unitaires, activez l'option --watch=false et limitez les navigateurs à ChromeHeadless pour éviter les ouvertures graphiques inutiles. Si votre suite de tests est volumineuse, envisagez de la paralléliser en créant plusieurs jobs qui exécutent des sous-ensembles de tests. Les builds Angular peuvent aussi être optimisés avec la configuration production qui active le tree-shaking, la minification et l'ahead-of-time compilation.
Vous pouvez aussi mettre en place des matrice de jobs pour tester sur plusieurs versions de Node ou plusieurs configurations Angular. Par exemple :
strategy:
matrix:
node-version: [18.x, 20.x]
steps:
- uses: actions/setup-node@v4
with:
node-version: ${{ matrix.node-version }}Cela garantit que votre projet fonctionne sur un spectre de versions.
Gestion des environnements et secrets
Un pipeline de production doit gérer plusieurs environnements : développement, staging et production. GitHub Actions permet de stocker des secrets (tokens d'authentification, clés API, etc.) au niveau du repository ou de l'organisation. Évitez absolument de les committer dans le code. Vous pouvez conditionner le déploiement sur l'environnement avec des variables d'environnement ou des étapes conditionnelles. Par exemple, déployer sur Netlify en preview pour les PR, et en production pour les merges sur main. Utilisez environment: production dans votre job de déploiement pour ajouter une couche de protection : GitHub peut demander une approbation manuelle avant de déployer en production.
Pièges courants et comment les éviter
Un piège classique est de faire confiance au cache npm sans jamais le nettoyer. Si une dépendance se corrompt ou si vous changez de version de Node, le cache peut servir des artefacts obsolètes et causer des erreurs cryptiques. Nettoyez le cache manuellement via les paramètres du repository si vous suspectez un problème. Un autre piège : oublier que GitHub Actions s'exécute dans un conteneur Linux, pas sur votre machine locale. Des chemins Windows ou des dépendances natives mal compilées peuvent passer localement mais échouer en CI. Toujours tester localement en mimant l'environnement CI, ou au minimum sur la même version de Node. Enfin, ne pas surveiller les durées de workflow : un pipeline qui dure 20 minutes tue la productivité. Profitez des artifacts et des caches, parallélisez les jobs, et éliminez les étapes redondantes.
Conclusion
Un pipeline CI/CD bien calibré pour Angular est un investissement qui paie rapidement. Avec GitHub Actions, vous avez une solution native, versionnée et transparente. La clé est de commencer simple (lint + test + build) puis d'ajouter du déploiement une fois que la base est solide. Optimisez progressivement en fonction de votre temps de feedback et des erreurs réelles que vous capturez. N'oubliez pas que le meilleur pipeline est celui que tout le monde comprend et utilise ; la complexité cache souvent des bugs.