Il y a plusieurs années, la mise en production (MEP) était un événement sacré qui mobilisait toutes les équipes IT. Expressions comme « Il y a une MEP de prévue », « Je prépare une MEP », ou « J’ai une MEP demain » faisaient frémir tout le monde dans les équipes techniques et produits. Cet événement était le point culminant de semaines de travail entre développeurs, testeurs et ops. La responsabilité d’une MEP était souvent un signe de confiance et de reconnaissance des compétences.

Les MEPs, pour certains, étaient source de stress et d’appréhension, tandis que pour d’autres, elles étaient l’occasion de démontrer leur maîtrise et leur importance. Ces déploiements étaient planifiés longtemps à l’avance et informaient tous les départements.

Lourdeur mentale

Avec le temps, beaucoup ont commencé à remettre en question la lourdeur de ce protocole, surtout pour des changements parfois mineurs. Les réveils matinaux pour suivre des procédures, qui parfois échouaient à cause d’erreurs, de bugs non identifiés en test, de problèmes de performance, de crashs de bases de données ou de bascules DNS qui ne se propagent pas, sont devenus source de frustration.

Le cérémonial des MEPs rappelait à certains leur importance, mais il était souvent mystifié, au détriment de la documentation de points cruciaux.

Les étapes pour désacraliser les mises en production

Pour transformer les MEPs en une procédure fluide et sans stress, voici 8 étapes à suivre :

1. Rendre les choses simples

Construire des applications que l’on maîtrise entièrement. Éviter les produits tiers dont la connaissance est limitée.

2. Utiliser Docker, Kubernetes et les micro-services

Si une application ne peut pas tenir dans une image Docker, il faut la découper ou l’abandonner. Bannir les machines virtuelles (VMs) et opter pour des conteneurs pour les applications (exception faite pour les runners CI/CD).

3. Fondation manuelle, applications automatiques

La fondation de l’infrastructure est exécutée manuellement (création/mise à jour d’un cluster), tandis que le processus de mise à jour des applications est automatisé (build Docker, versionnage, déploiement…).

4. NoOps

Permettre à tout le monde de déployer une nouvelle version. Chaque développeur, selon ses droits, peut déployer et revenir à la version précédente, éliminant ainsi la dépendance à un Ops Guru.

5. Partager les connaissances

Éliminer les secrets et les gourous concentrant toutes les connaissances. Rendre tout le monde au courant de l’architecture, de l’infrastructure et du fonctionnement.

6. Mises à jour régulières des éléments fondamentaux

Assurer chaque mois que les socles techniques sont à jour et ne pas hésiter à les mettre à niveau, même au risque de casser quelques applications, pour une tranquillité et une sérénité au quotidien.

7. Surveiller uniquement ce qui est important

Développer des outils internes pour surveiller exclusivement les points critiques des applications et alerter par les bons canaux. Éviter les faux positifs et se concentrer sur les alertes réelles.

8. Aller rapidement en production

Pour chaque petit changement, aller directement en production. Cela aide à identifier rapidement les problèmes et à les corriger immédiatement. Maintenir un seul environnement hors production, voire aucun selon la criticité de l’application, permet de réduire les coûts et d’optimiser les ressources.

En suivant ces étapes, il est possible de réaliser des mises en production fréquentes et sans stress, même avec une équipe limitée et sans Ops à temps plein. Cette méthode a permis à HK-TECH de réaliser chaque mois près de 200 mises en production sur une treintaine d’applications web et mobile.

Pour toute assistance en logiciels web et mobile ou en construction d’infrastructures cloud, n’hésitez pas à nous contacter à contact@thehktech.com ou à prendre un rendez-vous sur ce lien