Jenkins

Avant Jenkins, c’était le far west du déploiement.

Tu bossais des semaines sur une feature. Quand tu voulais merger ton code, c’était la panique :

— “Attends, t’as bien testé ?”
— “Oui oui, ça marche chez moi.”
— “Ok, on déploie.”
— Et BAM. Prod cassée.

Pourquoi ?
Parce qu’on développait chacun dans notre coin.
Les merges étaient des cauchemars, les tests étaient souvent manuels,
et on découvrait les bugs trop tard, une fois que tout était déjà en place.

Kohsuke Kawaguchi, un ingénieur chez Sun Microsystems,
en a eu marre de perdre son temps à corriger des bugs qui auraient pu être évités plus tôt.
En 2005, il crée Hudson (le futur Jenkins),
un outil qui va automatiser les builds, les tests et les déploiements.

L’idée ?
Chaque commit doit être testé immédiatement.
Si quelque chose casse, on le sait tout de suite, pas trois semaines plus tard.

Et là, révolution :

• Plus de merges cauchemardesques.
• Moins de “ça marche chez moi”.
• Une véritable collaboration entre devs.

Hudson devient vite indispensable, mais après des embrouilles avec Oracle,
le projet fork sous le nom Jenkins en 2011.

Depuis, Jenkins a inspiré toute la CI moderne.
Il a ouvert la voie à GitHub Actions, GitLab CI/CD, et bien d’autres.
Aujourd’hui encore, il tourne dans des milliers d’entreprises.

Tout ça parce qu’un dev a voulu arrêter de perdre son temps avec des merges foireux.

➡️ Et toi, t’as déjà vécu l’enfer du “ça marche chez moi” avant d’adopter la CI ?