CI/CD avec GitHub Actions : automatiser vos déploiements web de A à Z

Livrer du code rapidement et en toute confiance est devenu un avantage concurrentiel majeur. GitHub Actions s'est imposé comme la solution de référence pour mettre en place des pipelines CI/CD directement intégrés à votre dépôt, sans infrastructure externe à gérer. Dans cet article, nous explorons comment construire un pipeline complet — des tests automatisés jusqu'au déploiement en production — pour vos applications web Angular, React ou Node.js.

Qu'est-ce que GitHub Actions et pourquoi l'adopter ?

GitHub Actions est une plateforme d'automatisation intégrée nativement dans GitHub qui vous permet de déclencher des workflows à chaque événement sur votre dépôt : push, pull request, tag de release ou même selon un planning horaire. Contrairement à des solutions externes comme Jenkins ou CircleCI, Actions ne nécessite aucune infrastructure à maintenir et propose jusqu'à 2 000 minutes gratuites par mois pour les dépôts publics. Chaque workflow est défini dans un fichier YAML versionné dans votre code, ce qui garantit que la configuration de déploiement évolue en même temps que votre application. L'écosystème de la Marketplace recense plus de 20 000 actions prêtes à l'emploi pour Docker, AWS, Azure, Vercel, CapRover et bien d'autres cibles de déploiement.

Structurer un pipeline CI en plusieurs étapes

Un bon pipeline d'intégration continue se décompose en étapes indépendantes et parallélisables : installation des dépendances, lint, tests unitaires, vérification des types TypeScript, puis build de production. En découpant ces jobs, vous obtenez un retour rapide en cas d'échec sans attendre la fin de toutes les étapes. GitHub Actions permet de définir des matrices de tests pour exécuter votre suite de vérifications sur plusieurs versions de Node.js simultanément. Il est également recommandé de mettre en cache le répertoire node_modules entre les runs grâce à l'action actions/cache, ce qui peut réduire le temps d'installation de 60 à 80 % sur les runs ultérieurs. Enfin, l'utilisation de actions/upload-artifact vous permet de transmettre les artefacts de build (le dossier dist/) du job CI au job CD sans reconstruire l'application deux fois.

Déploiement continu : stratégies et bonnes pratiques

La partie CD (Continuous Deployment) du pipeline ne doit se déclencher que sur la branche principale et uniquement si tous les jobs CI sont passés au vert. Pour un déploiement vers un VPS ou un serveur CapRover, vous pouvez utiliser des secrets GitHub chiffrés pour stocker vos tokens d'API, clés SSH ou mots de passe — ils sont injectés comme variables d'environnement dans vos runners sans jamais apparaître dans les logs. Pour les applications Angular ou React, la stratégie la plus robuste consiste à construire l'image Docker dans le pipeline puis à la pousser vers un registre (Docker Hub, GitHub Container Registry), avant de déclencher un redéploiement distant. Il est conseillé d'adopter le déploiement blue-green ou les rolling updates pour garantir zéro temps d'arrêt lors des mises en production, surtout si votre application reçoit du trafic en continu.

Sécuriser et optimiser vos workflows GitHub Actions

La sécurité est souvent négligée dans les pipelines CI/CD. Commencez par limiter les permissions des tokens GITHUB_TOKEN au strict nécessaire en utilisant la directive permissions au niveau du workflow. Épinglez toujours les actions tierces à un SHA de commit plutôt qu'à un tag mutable pour éviter les attaques de type supply-chain. Intégrez des outils comme Dependabot pour maintenir vos actions à jour automatiquement, et ajoutez des étapes d'audit de sécurité (npm audit, Snyk ou Trivy pour les images Docker) dans votre pipeline CI. Côté performance, exploitez les runners plus puissants (ubuntu-22.04-16core) uniquement pour les jobs longs comme la compilation TypeScript ou la construction d'images Docker afin de maîtriser votre consommation de minutes. La mise en place de conditions if: github.event_name == 'push' vous permet d'éviter des déploiements non souhaités lors des pull requests.