CI/CD (4/5) — Automatiser : webhook & boucle complète

L’idée reçue

« Mon CI/CD marche : je clique Build Now et tout s’enchaîne. »

Tant que tu cliques, ce n’est pas continu : c’est du manuel déguisé. La vraie automatisation part d’un événement — un git push — sans intervention humaine. On branche ce déclencheur, puis on éprouve la boucle entière : un changement de code arrive tout seul en production.

À la fin de ce module, tu sauras…

Comprendre le mécanisme d’un webhook (push-based)
Activer le déclencheur côté Jenkins et côté GitHub
Prouver la boucle complète : push → build → push Harbor → deploy
Réaliser un rollback et comprendre les niveaux de retour arrière

01Ce qu’est un webhook

Un webhook est un appel HTTP que GitHub envoie à Jenkins au moment d’un push. Pas de scrutation, pas d’attente : l’événement pousse l’information vers Jenkins, qui lance le pipeline.

Comprends push vs poll, un choix d’architecture

Deux façons de déclencher : polling (Jenkins demande à GitHub « du nouveau ? » toutes les X minutes — simple mais avec latence et charge inutile) ou webhook (GitHub prévient Jenkins instantanément — efficace, réactif). Le webhook est push-based. Ce concept dépasse Jenkins : GitLab, GitHub Actions, Argo CD reposent tous sur des événements. (On verra le polling au module multibranch, utile quand le webhook n’est pas possible.)

02Activer le déclencheur côté Jenkins

Expérience 1

Autoriser le job à réagir aux hooks

Dans le job soria-web-ci → Configure → Build Triggers, coche :

[x] GitHub hook trigger for GITScm polling

Le job est désormais prêt à démarrer quand un hook GitHub arrive. Il reste à dire à GitHub où l’envoyer.

Comprends le nom trompeur de l’option

Malgré « polling » dans son nom, cette option réagit à un hook entrant : GitHub notifie Jenkins, qui vérifie alors le dépôt et lance le build. C’est bien du push-based, pas de la scrutation périodique.

03Configurer le webhook côté GitHub

Expérience 2

Dire à GitHub où notifier

Dans le dépôt GitHub → Settings → Webhooks → Add webhook :

Champ	Valeur
Payload URL	`https://jenkins.mondomaine.fr/github-webhook/`
Content type	`application/json`
Events	Just the push event
Active	coché

La barre oblique finale de /github-webhook/ est importante. Après avoir sauvegardé, GitHub envoie un ping : dans Recent Deliveries, tu dois voir une réponse 200.

Comprends pourquoi HTTPS et le 200 comptent

GitHub doit joindre Jenkins par une URL publique et valide — d’où l’intérêt du HTTPS mis en place en Phase 4 (jenkins.mondomaine.fr via HAProxy/ACME). Un 200 confirme que le hook arrive bien ; un 403/404/timeout indique un souci d’URL, de pare-feu, ou de certificat. Vérifier la livraison ici évite des heures de debug ensuite.

04Prouver la boucle complète

Expérience 3

Un changement qui va seul en production

Fais une modification visible dans SORIA Web, commit et push — sans toucher à Jenkins :

Manipule

cd ~/soria-web
sed -i 's/SORIA Web/SORIA Web v3/' index.html
git commit -am "Passage en v3"
git push

Puis observe, sans rien lancer manuellement :

Jenkins démarre tout seul (dans les secondes qui suivent).
Un nouveau tag gitsha-… apparaît dans Harbor.
La révision Helm s’incrémente.
Les Pods roulent, et le site affiche « v3 ».

Manipule

kubectl -n lab-soria get pods
helm -n lab-soria history soria-web | tail -n 3
curl -s https://demo.mondomaine.fr/ | grep -o "SORIA Web[^&lt;]*"

Observe

SORIA Web v3

Un simple git push a déclenché toute la chaîne, sans clic. C’est ça, le déploiement continu : le code part de ta machine et arrive en production, seul.

Comprends ce que tu viens vraiment de construire

Boucle complète : git push → webhook → Jenkins (checkout, tag, build, push Harbor) → Helm upgrade → cluster roule les Pods → site à jour. Chaque brique des phases 3-5 (image, registre, Kubernetes, Helm) est maintenant orchestrée automatiquement. C’est l’aboutissement du projet : une plateforme de livraison de bout en bout.

05Le rollback drill

Expérience 4

Revenir en arrière, proprement

Une nouvelle version pose problème ? Reviens à la précédente sans reconstruire quoi que ce soit :

Manipule

helm -n lab-soria history soria-web
helm -n lab-soria rollback soria-web 2
kubectl -n lab-soria get pods

Observe

Le cluster revient à la révision 2, les Pods roulent vers l’ancienne image. Ton registre Harbor conserve toutes les images taguées par commit : chaque version passée reste déployable.

Comprends trois niveaux de retour arrière

Tu disposes maintenant de plusieurs filets : Git (revenir au commit précédent → le pipeline redéploie l’ancienne version), Helm (rollback vers une révision passée, sans rebuild), Kubernetes (rollout undo sur le Deployment). Le bon niveau dépend du problème : bug de code → Git ; mauvaise release → Helm ; workload cassé → Kubernetes. Cette culture du retour arrière est indépendante de Jenkins.

✓Ce que tu retiens

Un webhook (push-based) déclenche le pipeline à chaque git push : plus de clic, la livraison devient continue. Tu as prouvé la boucle entière — code → build → Harbor → cluster → site à jour — et tu maîtrises le rollback à trois niveaux (Git, Helm, Kubernetes). La plateforme de livraison du projet est complète et réversible.

Mini-projet

La boucle vivante

À faire

Active le trigger côté Jenkins et crée le webhook côté GitHub (vérifie le 200 dans Recent Deliveries).
Fais un changement visible, push, et prouve que tout s’enchaîne sans clic.
Vérifie le nouveau tag Harbor, la révision Helm, et le site à jour.
Réalise un rollback Helm et prouve le retour à la version précédente.
Documente dans BookStack la boucle complète et les trois niveaux de rollback.

Fil rouge — Ton pipeline suit une seule branche (main). Mais un vrai projet a des branches (features, correctifs) qu’on veut tester automatiquement. Au dernier module CI/CD : le pipeline multibranch, qui découvre et construit chaque branche tout seul.

?Auto-évaluation

1. Quelle est la différence entre webhook et polling ?

Le webhook est push-based : GitHub notifie Jenkins instantanément à chaque push. Le polling est pull-based : Jenkins interroge périodiquement, avec latence.

2. Pourquoi le HTTPS de Jenkins est-il nécessaire pour le webhook ?

GitHub doit joindre Jenkins via une URL publique valide. Le HTTPS (Phase 4) rend jenkins.mondomaine.fr accessible et fiable ; un 200 confirme la livraison.

3. Quels sont les trois niveaux de rollback ?

Git (revenir au commit), Helm (rollback de release sans rebuild), Kubernetes (rollout undo sur le Deployment). Le choix dépend de la nature du problème.