En tant que développeur, je suis un grand partisan de l'intégration continue. Pour les non-initiés, l'intégration continue est une pratique d'ingénierie logicielle dans laquelle les modifications de code sont testées dès qu'elles sont validées. Cela permet de détecter les problèmes de manière précoce. Cela fournit également un retour d'information immédiat sur la qualité du code, ce qui permet d'identifier et de corriger immédiatement les problèmes.

Le déploiement continu est souvent mentionné dans le même souffle que l'intégration continue. Le déploiement continu est une extension de l'intégration continue dans le sens où, dès que les tests unitaires sont réussis, le code est immédiatement publié en production. En intégrant et en déployant en continu les modifications de code, les développeurs peuvent réduire les risques et adapter rapidement le produit aux besoins de l'entreprise. Ce processus, bien qu'incroyablement précieux pour les développeurs et les utilisateurs, peut encore être amélioré.

Comme dans un environnement de production, l'intégration du processus de gestion des incidents de votre équipe dans votre flux de travail d'intégration continue est un excellent moyen d'améliorer la communication et la transparence autour des builds ayant échoué. L'envoi des détails des builds ayant échoué à une plateforme de gestion des incidents telle que PagerDuty peut offrir un certain nombre d'avantages qui vont bien au-delà des notifications standard fournies par de nombreux outils d'intégration continue.

Pré-mortem

L’un des principaux avantages que les techniques de gestion des incidents peuvent apporter à l’intégration continue est le concept de « pré-mortem ». En termes de gestion de projet, un post-mortem est le processus d’examen et d’identification des éléments du lancement d’un projet qui ont réussi ou échoué. Bien que ce processus soit souvent effectué à la fin d’un projet, en termes de gestion des incidents, il implique de comprendre et de communiquer la cause profonde d’une défaillance critique.

En intégrant ce processus dans le flux de travail d'intégration continue, vous effectuez un pre-mortem. Avec un pre-mortem, vous recherchez les problèmes à l'avance. Quel problème peut potentiellement survenir et perturber le service et déclencher un incident. Les tests de défaillances et d'incidents potentiels perturbant le service pendant la phase d'intégration continue permettent aux équipes d'évaluer les menaces potentielles et d'apporter des modifications avant même que les choses n'atteignent l'utilisateur final.

Entraînement

La formation des développeurs juniors est un élément important de la réussite d'une équipe de développement. Malheureusement, la gestion des incidents dans un environnement de production peut être rapide et stressante. Même si l'équipe peut effectuer une analyse post-mortem le lendemain matin d'un problème survenu tard dans la nuit et qu'elle est atténuée, les informations qui peuvent être transmises lors de ces analyses post-mortem peuvent ne pas être aussi faciles à assimiler par les membres les plus novices de l'équipe. En intégrant les problèmes soulevés dans le flux de travail d'intégration continue directement dans votre processus de gestion des incidents, vous pouvez offrir aux développeurs juniors l'occasion d'en apprendre davantage sur le processus dans un environnement nettement moins stressant.

Croissance

Je suis un grand fan des revues de code. J'ai toujours trouvé qu'elles constituaient un outil important pour la croissance professionnelle de chaque membre de l'équipe de développement, quel que soit son niveau d'expérience. En associant une plateforme de gestion des incidents au workflow d'intégration continue, vous pouvez utiliser les détails des builds ayant échoué en complément du processus de revue de code pour identifier les zones spécifiques du code qui doivent être discutées plus en détail. C'est une excellente occasion non seulement d'améliorer la qualité du code, mais aussi de garder l'importance de la suite de tests à l'esprit de l'équipe.

La gestion des incidents est souvent considérée comme un processus réactif, mais en intégrant un ensemble d'outils et un état d'esprit d'intégration continue, vous pouvez la transformer en un processus proactif. Réagir aux incidents et les atténuer avant qu'ils ne se produisent permettra à vous et à votre équipe de garder une longueur d'avance, ce qui permettra de réduire la dette de code et d'améliorer la stabilité et la fiabilité globales de votre produit.