CI/CD et DevOps

Quand déployer fait peur, on déploie rarement ; quand on déploie rarement, chaque mise en production emporte trois mois de changements, et c'est justement ce qui casse. La sortie de ce cercle est mécanique : automatiser jusqu'à ce que publier ne demande plus qu'une commande. Chez nous, une mise en production part d'une ligne de commande, exécute les tests, construit l'image, la déploie, et le retour arrière consiste à redéployer la version précédente. Ce que ça donne, mesuré sur les trente derniers jours : environ 150 mises en production par jour, réparties sur 65 projets, sans réunion et sans fenêtre de livraison. C'est cette chaîne-là que nous installons chez nos clients.

Ce que vous recevez

Les livrables

• check_circleLa chaîne de construction et de déploiement en place, déclenchée automatiquement
• check_circleLes environnements séparés : développement, préproduction, production
• check_circleLa procédure de mise en production et de retour arrière, tenant sur une page
• check_circleL'historique des versions déployées, avec ce que chacune contenait

Questions fréquentes

Nous n'avons pas de tests. C'est bloquant ?

Non. On installe d'abord la chaîne, puis on ajoute des tests sur ce qui casse le plus souvent — en général les calculs et les règles métier. Attendre une couverture complète pour automatiser revient à ne jamais commencer.

Kubernetes ?

Rarement justifié en dessous d'une certaine taille. Nous faisons tourner des dizaines d'applications en production sur une orchestration nettement plus simple, que deux personnes peuvent comprendre entièrement. Choisir un outil qu'on ne maîtrise pas, c'est déplacer le risque, pas le réduire.

Vous intervenez sur une chaîne existante ?

Oui. GitHub Actions, GitLab CI, Jenkins : le principe est le même. Nous reprenons l'existant, nous le fiabilisons, et nous ne le remplaçons que si le maintenir coûte plus cher que le refaire.