Github Actions

Avec Jenkins, on a automatisé l’intégration.
Avec Docker, on a résolu les problèmes d’environnement.

Mais… y’avait encore un souci : la configuration de la CI/CD.

Avant GitHub Actions, mettre en place une CI/CD, c’était souvent la galère :

— Il fallait installer Jenkins (ou un autre outil) sur un serveur.
— Il fallait configurer des webhooks pour déclencher les builds.
— Il fallait gérer les permissions, les runners, et parfois, ça finissait par un scp à la main en prod (oui, avoue, on l’a tous fait).

Bref, c’était lourd.

Puis en 2019, GitHub a sorti GitHub Actions.
Et là, c’est devenu beaucoup trop simple.

Pourquoi ça a changé le game ?

• CI/CD native à GitHub → Plus besoin d’installer un outil externe, tout est intégré.
• Des workflows en YAML → Simple, lisible, versionné dans le repo.
• Des actions réutilisables → Plus besoin de tout coder soi-même, y’a déjà des milliers d’actions prêtes à l’emploi.
• Un pricing agressif → Gratuit pour les repos publics, et ultra compétitif pour le reste.

Résultat ? Une adoption massive.
En quelques années, GitHub Actions a enterré Travis CI et CircleCI,
et a grignoté des parts de marché à GitLab CI.

Aujourd’hui, c’est l’un des standards de la CI/CD moderne.

Mais… déployer du code, c’est bien.
Déployer de l’infrastructure, c’est mieux.

Et c’est là qu’un nouvel acteur entre en jeu : ArgoCD et la révolution GitOps.