Formation DevOps écrite
Pourquoi mettre en place des retours d’information pour rendre vos déploiements en production plus sûrs ?
Sur un marché concurrentiel comme le vôtre, séparer le développement, l’assurance qualité et l’exploitation n’est guère acceptable si vous souhaitez servir vos clients rapidement et répondre en permanence à leurs attentes. Pourtant, bien que la plupart des développeurs se plaignent de la bureaucratie, ils hésitent toujours à déployer seuls en production, même quand ils peuvent collaborer avec des spécialistes de l’assurance qualité et de l’exploitation au sein de leur équipe. Voyons quelles techniques et mesures peuvent rendre ces déploiements plus sûrs.
Comment maintenir un flux DevOps continu
Pour un flux fluide et continu, les organisations DevOps qui réussissent le mieux déploient fréquemment de petits lots de changements en production. Chacun dans l’équipe peut ainsi comprendre et évaluer les changements et les corriger au besoin.
Un pipeline de déploiement automatisé ne suffit pas. Intégrez-y la télémétrie d’exploitation pour obtenir rapidement des retours sur les effets des changements en production et en préproduction. Cultivez aussi une conviction commune dans votre organisation : chaque membre de l’équipe DevOps est responsable du bon fonctionnement et de la continuité de l’ensemble du flux de valeur et du pipeline.
Appuyez-vous sur la télémétrie pour sécuriser vos déploiements
Un changement et son déploiement ne sont « terminés » que lorsque vous avez prouvé qu’ils fonctionnent comme prévu. Après chaque déploiement, surveillez de près les indicateurs des modules modifiés, les nouveaux indicateurs éventuels et ceux des autres composants que le changement pourrait affecter.
Malgré les tests automatisés en préproduction et la supervision du système testé grâce à la télémétrie, des problèmes surviendront encore en production. Vous ne pouvez pas tous les prévenir, mais vous pouvez vous préparer à les résoudre. Si un changement bloque le pipeline, réunissez les spécialistes nécessaires pour corriger le problème et rétablir son bon fonctionnement. Voici trois méthodes fréquemment utilisées :
- Désactiver la fonctionnalité : C’est le moyen le plus simple de corriger un problème. Aucun déploiement urgent de code n’est nécessaire. Désactivez la fonctionnalité avec son interrupteur. Vous n’avez pas à corriger dans l’urgence les éléments défectueux du déploiement. L’équipe peut prendre le temps de bien comprendre la cause profonde et d’améliorer ses méthodes afin de réduire le risque que le problème se reproduise.
- Corriger le problème par une nouvelle modification : Déployez du nouveau code pour corriger le problème. Cette méthode est risquée dans les organisations informatiques traditionnelles. Elle peut toutefois fonctionner efficacement et en toute sécurité en DevOps si les tests et les déploiements sont automatisés et si la télémétrie de production est complète.
- Annuler le changement : Vous retirez le code erroné et le problème disparaît, du moins on l’espère.
Donnez à vos développeurs des retours issus de l’exploitation réelle
Organisez une rotation des responsabilités d’exploitation dans votre équipe DevOps pour que chacun traite des incidents. Tous les acteurs du flux de valeur découvrent ainsi les difficultés et les responsabilités des unités en aval. Confiez des astreintes pour les interventions imprévues à vos développeurs, testeurs, architectes, concepteurs, responsables et directeurs, afin qu’ils reçoivent eux aussi des alertes d’incident à trois heures du matin. Chacun comprend alors concrètement les conséquences des décisions prises au quotidien.
Cette rotation évite que les spécialistes de l’exploitation se sentent isolés. Chacun dans votre équipe DevOps contribue à trouver un équilibre entre la résolution des incidents de production, la réduction de la dette technique et le développement de nouvelles fonctionnalités. En réveillant les architectes et développeurs à trois heures du matin, vous pouvez vous attendre à des corrections plus rapides que jamais.
Quand les développeurs observent leurs clients utiliser le logiciel, ils comprennent souvent soudain ce qu’ils devraient améliorer en priorité. Cela vaut aussi pour les architectes, concepteurs, développeurs et testeurs qui observent les unités internes situées en aval du cycle de vie logiciel. En comprenant les conséquences de leur travail sur ces unités, ils découvrent comment améliorer la qualité et ajuster leurs livrables pour faciliter le travail en aval. Toute l’équipe DevOps commence à prendre en charge les exigences non fonctionnelles d’exploitation dans son backlog au quotidien. Cela n’est possible qu’avec des boucles de retour rapides et continues dans votre organisation.
Demandez à vos développeurs d’exploiter leur propre système
Il est très difficile de transmettre aux équipes de développement les enseignements tirés des systèmes de production. Certaines organisations DevOps de premier plan, dont Google, chargent donc leurs équipes de développement de l’exploitation du logiciel pendant et après les premiers lancements. Tant que le produit est géré par les développeurs, les ingénieurs d’exploitation jouent un rôle de conseil. Une fois le produit suffisamment stable en production pendant environ six mois, il est confié aux équipes d’exploitation. Ce transfert ne peut avoir lieu que si le produit satisfait déjà à différents critères portant notamment sur les défauts passés et actuels, la couverture de télémétrie, les incidents en dehors des heures de travail, le faible couplage de l’architecture et la sécurité des changements et déploiements.
Si des problèmes importants de conception ou de code sont découverts alors que l’exploitation gère le produit, celui-ci peut être rendu aux développeurs. Dans cette phase, les développeurs stabilisent le logiciel et les ingénieurs d’exploitation les conseillent.
CONCLUSION
Ce chapitre a présenté différentes techniques pour améliorer la fluidité et la sécurité de vos pipelines de déploiement DevOps.
Ces techniques montrent comment les développeurs et les ingénieurs d’exploitation de vos équipes DevOps peuvent collaborer avec un respect mutuel exemplaire.
