Comment je me prépare et teste pour mes mises en production
Les versions et la gestion des versions sont une partie essentielle de notre travail. Livrer le bon produit aux clients les rendra heureux. Effectuer une sortie sans accroc nous rendra, nous qui sommes impliqués dans le processus, heureux.
Comment pouvons-nous assurer une publication sans accroc ?
Pour avoir participé à un grand nombre de sorties, je peux dire qu’il existe quelques points clés qui peuvent aider à réussir la gestion des versions.
Laissez-moi vous les présenter.
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
Une sortie réussie commence pendant le développement.
Identification des cas de test
Une bonne gestion des versions commence bien avant le jour de la sortie, dès que la fonctionnalité à publier est en phase de développement. Pendant cette période, la fonctionnalité doit recevoir l'approbation QA. Cela signifie que nous devons tester tous les scénarios possibles auxquels nous pouvons penser, et qui ont du sens pour la fonctionnalité concernée, afin de valider qu’elle fonctionne comme attendu. Certains de ces scénarios seront vérifiés par des tests automatisés, alors que pour d'autres, il est soit trop difficile, soit pas utile, de mettre en place une automatisation.
Lorsque nous identifions le type de test à effectuer pour une fonctionnalité donnée, nous devons garder à l'esprit que lors de sa première mise en production, il faut la tester intégralement. Nous devons nous assurer qu’aucun problème critique ne sera découvert par les clients. Nous devons valider les exigences. Et nous devons garantir les bonnes performances de la fonctionnalité.
Des retards et des problèmes lors des tests peuvent impacter de manière significative les délais lors de la préparation des mises en production. L’intégration de bonnes pratiques de gestion des versions permettra d’assurer la fiabilité et la prédictibilité des tests comme des déploiements.
Mais une fois la fonctionnalité en production, sauf si elle nécessite des mises à jour, il n’est pas nécessaire de la tester aussi minutieusement à chaque future publication du même socle de code. Son comportement ne changera que si le code sous-jacent a été modifié ou si une modification externe d’une de ses dépendances intervient. Le reste du temps, un test de santé de la fonctionnalité suffira, ce qui inclura évidemment les cas de test prioritaires.
Cela étant dit, lorsque la fonctionnalité est en développement, assurez-vous d’évaluer : combien de cas de test vous devez tester ; combien de temps vous disposez pour les tests ; quels sont les cas de test critiques ; et lesquels vous exécuterez à chaque publication.
Cela permet de déterminer quels sont les cas de test à automatiser. Priorisez l'automatisation au moins pour les fonctionnalités critiques. Pour les autres tests, documentez-les, soit dans votre système de gestion de projet (par exemple Jira), soit dans l’outil de gestion de test que vous utilisez. Ainsi, ils ne seront pas oubliés et pourront être exécutés dès qu’une mise en production l’exige.
Exécution des tests dans le CI
Une fois que vous disposez de tests automatisés, vous devriez commencer à les exécuter via le CI, sur les environnements de dev, de façon périodique. D’autres fonctionnalités étant développées avant la sortie, il est judicieux de s'assurer que la fonctionnalité que vous comptez publier fonctionne toujours correctement, surtout si vous l’avez déjà validée durant le sprint. Exécuter les tests de la fonctionnalité qui vous intéresse, par exemple quotidiennement, vous offrira un retour rapide en cas de corrections nécessaires, notamment pour les bugs introduits par d’autres évolutions du système.
Détecter tôt les éventuels bugs de la fonctionnalité à publier laissera largement le temps d’appliquer les corrections nécessaires et de la retester sans le stress lié au temps limité du cycle de sortie. Plus votre couverture des exigences par les tests automatisés sera importante, moins vous aurez de bugs à découvrir pendant la phase de mise en production.
La préproduction est importante et doit contenir une marge de sécurité.
Délais
La phase de mise en production comprend généralement une période de tests dans un environnement d’intégration préproduction, en dehors du jour ou de la période de mise en production elle-même. En tant que testeur impliqué dans la sortie, je veille toujours à réserver des créneaux convenables pour que la phase de préproduction me permette de tester correctement les fonctionnalités à livrer.
Je prévois également toujours une marge de sécurité, car je m’attends à ce que des problèmes imprévus surviennent dans le processus de gestion de publication, qu’il s’agisse de bugs des fonctionnalités à livrer ou de facteurs externes. Pour en citer un, les environnements de préproduction sont des environnements de test et sont souvent moins fiables qu’ils ne le devraient. Bien souvent, ils fonctionnent très lentement ou deviennent indisponibles un temps, justement lors des tests de validation.
Avoir un temps tampon supplémentaire est toujours une bonne idée, et même si vous ne l’utilisez pas, ce n’est pas grave. Vous pouvez donner votre approbation avant que le temps de test alloué ne soit écoulé, car vous pouvez consacrer le reste du temps à travailler sur autre chose. Il est bien pire de ne pas avoir de temps tampon et d’en avoir besoin, car, dans ce cas, vous devrez tant bien que mal effectuer tous les tests nécessaires dans un délai réduit. Cela peut entraîner l’absence d’exécution de certains cas de test, ce qui peut à son tour conduire à ce que certains bugs ne soient identifiés que directement en production.
Périmètre
Un autre aspect important de la pré-livraison, de mon point de vue, est d’avoir un coordinateur dédié à la gestion des releases. Pour moi, cela signifie une personne qui s’occupe de certains aspects, dont le premier est : vérifier le périmètre de la release. Avant de commencer à tester une release, le testeur a besoin de savoir quoi tester. Tout se résume donc au périmètre de la release.
Les responsables produits, également appelés PO ou BA, attendent que certaines fonctionnalités soient incluses dans la release, décision prise dès le début du développement. Cependant, le code intégré à la release ne couvre pas toujours exactement le périmètre attendu par l’équipe produit. Parfois, certains oublient de pousser du code sur la branche à partir de laquelle la build de la release est effectuée. Pire encore, il se peut que du code non destiné à cette branche soit intégré. Il peut s’agir de fonctionnalités non finalisées et non validées par la QA, ou de fonctionnalités qui ne font pas partie du périmètre actuel.
Pour garantir que le périmètre sera respecté, le coordinateur de release doit comparer le périmètre attendu au périmètre réel. Le périmètre attendu devrait provenir des responsables produits et être clairement formulé dans un document (et peut-être dans votre plan d’assurance qualité). Par exemple, vous pouvez disposer de documents de planification qui présentent les jalons du projet ainsi que les éléments inclus dans chacun d’eux.
Pour le périmètre réel, un journal de modifications (changelog) doit être extrait du système de gestion de versions (VCS, par exemple Git) utilisé pour le projet. Ce changelog reflètera tous les commits effectués durant la phase de développement sur la branche à l’origine de la build de la release. Idéalement, si vous travaillez de façon organisée, chaque commit devrait avoir une description pointant vers un ticket Jira correspondant. De cette manière, vous pouvez vérifier tous les éléments Jira dont le code est inclus dans la release, et lesquels n’auraient pas dû l’être. Bien sûr, si ces commits concernent des corrections de bugs nécessaires, ce n’est pas un problème. Ce que vous ne voulez pas, c’est que ces commits correspondent à des fonctionnalités inachevées ou à des travaux liés à des fonctionnalités qui ne doivent pas être déployées en production dans la release actuelle.
En explorant des techniques avancées de gestion des releases, vous verrez qu’intégrer vos processus avec des solutions de gestion de tests conçues pour Jira peut offrir un flux de travail plus cohérent et efficace
Chaque fois qu’une différence est détectée entre le périmètre attendu et le périmètre réel, le coordinateur de gestion des releases doit échanger avec l’équipe produit et les responsables de l’équipe de développement afin d’identifier la meilleure démarche à suivre. Si les commits sortis du périmètre correspondent à des fonctionnalités inachevées, le mieux est de les retirer. En effet, vous êtes déjà en phase de pré-livraison, et vous ne souhaitez pas prendre le risque de voir le code restant être développé et testé dans la précipitation juste pour pouvoir l’intégrer à la release. C’est risqué, car cette précipitation peut entraîner l’oubli de certains cas de test, et l’introduction de bugs critiques en production. Il est préférable, dans ce cas, de laisser les travaux restants sur ces fonctionnalités pour une future release, afin qu’ils soient réalisés correctement.
Les tests
Une fois le périmètre clarifié, la phase de test peut démarrer. Lors de la phase de test pré-production, vous devez revalider l’ensemble des fonctionnalités que vous livrez. Imaginez que c’est la première fois que vous les examinez, et testez chaque scénario que vous aviez validé durant le développement. Lancez les tests automatisés déjà créés, mais dans l’environnement de pré-production, et n’oubliez pas les scénarios non automatisés. Effectuez une régression complète sur cette fonctionnalité, tout simplement parce qu’une fois dans cette phase de gestion des releases et en pré-production, il y a sans doute d’autres équipes qui vont devoir livrer dans la même fenêtre de temps. C’est en réalité la première fois que toutes les dépendances sont réunies, avec du code prêt pour la production, dans le même environnement. Et ceci, en théorie, est la configuration qui sera utilisée en production dès la release.
Sauf si des problèmes sont découverts durant les tests, et que des correctifs sont nécessaires. Si cela se produit, vous devez réfléchir à ce que vous devrez retester. Que le correctif soit sur votre code ou sur une dépendance externe, si les changements affectent votre fonctionnalité, vous devrez prévoir un nouveau tour de tests. Assurez-vous de retester au minimum les fonctionnalités critiques.
Cela peut sembler rébarbatif, surtout si de nombreux correctifs sont apportés lors de cette phase. Cependant, il est impossible de prévoir avec certitude l’impact que ces correctifs peuvent avoir sur différentes parties de votre fonctionnalité.
De petits changements peuvent entraîner d’énormes effets secondaires, il vaut donc mieux s’ennuyer mais être sûr que la fonctionnalité critique fonctionne toujours correctement, plutôt que de regretter de ne pas avoir assez testé.
Et bien sûr, si vous découvrez un bug mineur au cours de cette phase, ne vous embêtez pas à le corriger maintenant. Encore une fois, il ne faut pas précipiter une implémentation ou des tests sur une fonctionnalité qui fonctionne autrement parfaitement, au risque de la désorganiser.
Pendant la mise en production, la communication et les tests sont essentiels.
Une fois que la fonctionnalité a été validée dans l'environnement de préproduction, elle est prête à être déployée en production.
Communication
En ce qui concerne la mise en production, le coordinateur de gestion des mises en production a plusieurs tâches à accomplir. Tout d'abord, la date et l'heure de la mise en production doivent être définies à l'avance et communiquées à toutes les parties impliquées. Je trouve qu'il est très utile, pour la gestion des mises en production, d'ajouter la date et l'heure de la mise en production comme réunion dans les calendriers des participants afin qu'ils puissent organiser leur journée, une tâche qui peut être réalisée par le coordinateur.
Le jour de la mise en production, le coordinateur doit rappeler à tous les intervenants les échéances de la mise en production. Idéalement, la communication doit se faire sur un canal utilisé par tous, par exemple Slack. Disposer d’un canal Slack dédié où tous les aspects importants sont partagés garantit que chaque personne impliquée a la même compréhension de l’avancement des étapes de la mise en production, du périmètre, des problèmes découverts et des personnes à contacter pour les résoudre. Cette communication permet de s’assurer que toute personne qui doit être informée le sera effectivement, contrairement à une communication verbale (où une absence pourrait passer inaperçue).
Le coordinateur de gestion des mises en production doit suivre et annoncer les étapes clés de la mise en production sur ce canal, comme le début de la mise en production ou encore la validation finale. De plus, chaque partie impliquée dans la mise en production doit communiquer via ce canal lorsqu’elle effectue ses étapes attribuées afin que tout le monde soit informé de l’état d’avancement. Si une personne nécessaire à un moment donné n’est pas disponible, le coordinateur doit contacter les personnes appropriées pour assurer le bon déroulement de l'opération.
Les tests
Pendant la mise en production, il est impératif de tester à nouveau la nouvelle fonctionnalité dans son intégralité. En effet, bien que la fonctionnalité ait été validée dans d’autres environnements de test, ceux-ci ne sont pas identiques à 100 % à l’environnement et aux ressources de production.
Pour éviter tout comportement imprévu lié à la fonctionnalité déployée, il est important d’exécuter tous les tests automatisés disponibles, ainsi que les tests manuels définis dans vos cas de test. Ne validez jamais une fonctionnalité en production sans l’avoir testée.
Supposer que la fonctionnalité fonctionne en production ne signifie pas qu'elle fonctionne réellement.
Vérifiez-le, testez-la.
Après la mise en production
Voilà, la mise en production est terminée. Mais, s’assurer que la fonctionnalité fonctionne correctement va au-delà des tests réalisés durant la phase de mise en production.
Une fois ceci terminé, assurez-vous que vos tests automatisés s’exécutent dans la CI pour la production. Cela permettra de détecter tout comportement indésirable provoqué par des modifications externes dont vous n’auriez pas connaissance.
Surveillez en permanence la performance de la fonctionnalité afin de garantir que la charge en production et l’utilisation par les clients n’entraînent pas de dégradation des performances. Et veillez à rester attentif aux retours et aux signalements de problèmes de vos clients. Ils peuvent révéler des zones qui ne fonctionnent pas correctement, vous permettant ainsi de planifier rapidement une mise à jour si nécessaire.
Et, dans le cas où la mise en production ne se serait pas déroulée comme prévu, n’oubliez pas d’organiser une rétrospective post-production. Ce sera l’occasion d’aborder tous les problèmes survenus au cours du processus de gestion de la mise en production, et d’assigner les actions correctives aux personnes concernées afin que la prochaine mise en production se passe sans accroc et avec succès.
