Après notre dernier article sur Microsoft Azure DevOps, qui portait sur l'affinement des exigences, l'exécution de sprints et la collaboration, nous nous concentrons sur la livraison continue de nouveaux développements et de tests. Dans ce contexte, nous aborderons également le concept « Continuous Integration and Continuous Delivery » (CI/CD).
L'intégration continue ou Continuous Integration décrit une pratique de développement qui exige que le code développé soit stocké régulièrement (par exemple quotidiennement) dans un répertoire commun - le module correspondant dans Azure DevOps est appelé Repos. Un dépôt et un système de contrôle de version peuvent garantir que plusieurs développeurs peuvent vérifier le code, construire des artefacts via un pipeline de construction (Build) et les tester automatiquement. Il s'agit généralement de tests unitaires et d'intégration automatisés.
Dans notre scénario, il existe une branche DEV pour l'état actuel du développement et des branches de fonctionnalités qui sont utilisées par les développeurs 1-n pour travailler sur une fonctionnalité spécifique. Pour chaque demande de poussée dans cette branche (un développeur vérifie dans le code les modifications apportées à la fonctionnalité depuis son environnement de développement local vers la branche de la fonctionnalité), une révision du code peut être insérée en tant qu'étape ou unité automatique et des tests d'intégration peuvent être définis. Ainsi, les erreurs éventuelles peuvent être détectées à un stade précoce et corrigées directement, avant même qu'une fonctionnalité cohérente ne soit déployée pour des tests manuels dans un environnement de test.
La livraison continue décrit une méthode permettant de s'assurer que les logiciels sont dans un état publiable tout au long de leur cycle de vie. Ainsi, vous avez toujours un retour d'information rapide et automatisé concernant l'état de préparation à la production d'un système. Cela permet non seulement de réduire les coûts, mais aussi le temps et les risques liés à la mise en œuvre de changements progressifs.
Mais comment Azure DevOps soutient-il ces méthodes ? Dans Azure DevOps, il y a le module "Pipelines". À l'aide de ce module, un scénario d'environnement précis peut être mis en place et défini - dans notre exemple de projet, nous avons mis en place les environnements AQ, UAT et PROD. Si le build précédemment créé dans la branche DEV (à partir des branches de fonctionnalités) a réussi, un pull request peut être fait à la branche Master, créant un build qui peut être déployé dans nos environnements au sein d'une version (voir à gauche ci-dessous) :
Une fois le build sans erreur, il peut être automatiquement déployé dans n'importe quel environnement. Des portes intermédiaires peuvent également être intégrées, par exemple pour une validation automatique ou manuelle avant le passage à l'environnement suivant. Les étapes d'un déploiement peuvent être facilement configurées et paramétrées dans Azure DevOps :
Le statut de déploiement peut alors être affiché dans une vue d'ensemble des versions :
En résumé, l'objectif de versions plus petites et plus fréquentes, ainsi que leur cohérence et leur rapidité, est atteint grâce à un degré élevé d'automatisation.
Après le déploiement d'une nouvelle version dans l'environnement d'assurance qualité (QA), les nouvelles fonctionnalités sont testées. Jusqu'à présent, seul un test d'unité et d'intégration automatisé était effectué au sein de la construction, ce qui garantissait l'absence d'erreurs techniques par rapport à une unité ou l'intégration des modules entre eux. Dans le contexte du DevOps, on parle également de tests continus, qui prévoient le processus d'exécution de tests automatisés dans le cadre du pipeline de déploiement.
En plus des tests automatisés, il est souvent nécessaire de tester manuellement le professionnalisme des fonctions et des caractéristiques. C'est le cas, par exemple, lorsque l'automatisation des cas d'essai entraîne des coûts élevés. Dans ces cas, une gestion structurée des tests est utile. La gestion des tests est une mesure d'accompagnement qui couvre l'ensemble du processus de test. Elle comprend la planification, le suivi et le contrôle des activités de toutes les étapes de test. Garder une vue d'ensemble de toutes les activités, données et statuts est l'art d'une bonne gestion des tests. C'est pourquoi, dans la pratique, la gestion des tests est idéalement toujours soutenue par des outils, car c'est la seule façon de garantir un flux d'informations complet entre tous les participants au projet.
En général, les tests suivent les étapes suivantes :
Le statut d'un bug, de l'identification à la résolution, peut être cartographié dans Azure DevOps comme suit :
Bien entendu, Azure DevOps offre également la possibilité de suivre le déroulement de la planification et de l'exécution des tests. À cette fin, les tableaux de bord déjà présentés dans un article précédent peuvent être réutilisés.
Avec le module "Test Plans", Azure DevOps prend en charge toutes les phases de la gestion des tests. Les tests sont divisés en "suites de tests", "cas de tests" et "étapes de tests".
Les suites de tests sont conçues pour regrouper les cas de tests en scénarios de tests séparés afin d'identifier facilement quels scénarios de tests ont déjà été exécutés avec succès. Les cas d'essais sont utilisés pour valider les différentes parties du déploiement de l'application/fonction afin d'en vérifier la bonne exécution, l'exactitude et les exigences métier. Pour vérifier cela, les étapes d'un test sont exécutées et marquées comme réussies ou défectueuses (bug). L'erreur est expliquée en conséquence afin qu'elle puisse être retracée par un développeur par la suite.
Azure DevOps est un outil mature qui soutient les pratiques modernes d'intégration continue et de livraison (CI/CD) des articles de livraison. Complété par la gestion des tests, Azure DevOps offre de nombreuses fonctionnalités utiles pour l'assurance qualité et la gestion des cas de tests ainsi que pour le suivi de bug et corrections de bug.
Dans notre prochain article, nous examinerons de plus près les modules Sprint Review et Retrospective et nous verrons dans quelle mesure Azure DevOps propose une solution intégrée dans ce domaine également.
