Docker

Jenkins a résolu un gros problème : détecter les bugs dès l’intégration.

Mais il en restait un autre, bien plus vicieux…

Les environnements.

— “Chez moi, tout marche nickel.”
— “Ah bon ? Parce qu’en prod, ça plante.”
— “Ah… T’es sûr que t’as la bonne version de Node ?”
— “Attends, c’est quoi la version de la base de données déjà ?”
— “Noooon ! J’avais oublié d’installer une dépendance…”

On perdait des heures (voire des jours) à corriger des écarts entre les environnements de dev, de test et de prod.

Jusqu’à ce qu’un mec débarque en 2013 avec une idée simple mais game changer :

“Et si on mettait tout dans un container standardisé, qui marche partout pareil ?”

Ce mec, c’est Solomon Hykes.
Son invention ? Docker.

Avec Docker, fini les excuses.
Ton code tourne dans un container identique, que ce soit sur ta machine, sur un serveur, ou en prod.

Résultat ?

• Moins de “ça marche chez moi”.
• Des builds et des tests reproductibles.
• Des déploiements plus rapides et plus fiables.

Et surtout, Docker a ouvert la voie à Kubernetes,
qui allait bientôt changer la gestion des infrastructures… mais on n’en est pas encore là.

Parce qu’avant Kubernetes, un autre outil a marqué un tournant dans le CI/CD…

Un outil qui a rendu l’automatisation accessible à tous, directement dans GitHub.

Son nom ? GitHub Actions.

(Et ça, on en parle demain. 😉)