Responsabilité totale
Lors d’un précédent blog de cette série, nous avons discuté de tout ce qui était nécessaire pour transformer des idées, améliorations ou besoins distincts en features concrètes. Il s’agit de descriptions de petites parties de la fonctionnalité d’une solution numérique, rédigées du point de vue de l’utilisateur final.
C'est à partir de là que débute la véritable phase de livraison, où les fonctionnalités sont construites, testées et maintenues à niveau. Pour ce faire, une équipe produit multidisciplinaire entre en action. Elle est responsable de l’ensemble du processus, de l’implémentation de nouvelles fonctions à l’exploitation de tout ce qui est déjà en production. Chaque équipe est responsable du début à la fin de ses délivrables, et ce, tout au long de leur cycle de vie.
Voici la base du véritable état d’esprit DevOps : you build it, you run it. Cette conscience entraîne souvent une amélioration implicite de la qualité. Si vous êtes responsable en cas d’éventuels problèmes la nuit ou le week-end, vous veillerez à ce que le système soit très stable et vous intégrerez autant que possible de résilience dans le logiciel. Par conséquent, ces équipes doivent par définition être stables et matures. Que vous optiez plutôt pour l’approche DevOps ou SRE, cela ne fait pas une grande différence pour notre projet. C’est pourquoi, dans ce blog, nous utilisons la dénomination générale « équipe produit ».
Gagnez en efficacité grâce à la gestion transversale
Outre la responsabilité de chacun, il y a également de nombreuses choses qu’il est préférable de mettre en place de manière transversale. Toutes les équipes ne doivent pas inventer l’eau chaude. Les systèmes de support DevOps comme Atlassian et Azure DevOps contiennent des éléments essentiels pour garantir un bon fonctionnement. Outre le contrôle des sources et les pipelines pour mettre en place des systèmes CI/CD (Continuous Integration et Continuous Deployment), des outils de collaboration intégrés sont également disponibles pour faciliter un fonctionnement agile. Avec les processus, l’outil assure des boucles de feed-back continu afin de faire circuler les connaissances et les expériences pendant le processus. De cette manière, vous restez à l’écoute (« construisons-nous l’élément comme il faut ? ») et vous optimisez le fonctionnement et les connaissances d’une équipe.
Ce type de processus et d’outils est déployé et entretenu de manière transversale entre les différentes équipes DevOps, afin qu’ils puissent être utilisés facilement et qu’ils favorisent vraiment une équipe. Un équilibre doit toujours être trouvé en ce qui concerne le contenu des processus et pipelines proprement dits. À quelle point peut-on diriger de manière transversale et quelle est la responsabilité de chaque équipe ? Comme nous l’avons dit, les équipes assument une responsabilité end-to-end et c’est à elles que revient le dernier mot. Dans le même temps, un processus de livraison de logiciels est très rationalisé et les étapes à entreprendre sont assez fixes. Une plus grande maturité en matière de développement de logiciels va souvent de pair avec davantage de processus et d’outils transversaux.
Tester, tester, tester
Le schéma ci-dessous donne un aperçu de haut niveau des différentes phases et étapes que nous voyons dans un processus de livraison de logiciel Agile. En cas de pipeline automatique, ces étapes sont entièrement automatisées.
Nous nous trouvons dans la phase qui suit le point d’engagement auquel l’organisation a décidé de réellement lancer le développement concret d’une fonctionnalité. La user story écrite en langage humain est convertie en lignes de code.
Dans le cadre de Continuous Delivery, le processus de construction (CI) fait du code un artefact binaire(1). C’est également le moment idéal pour soumettre le code à différents tests afin que nous puissions immédiatement nous faire une idée de sa qualité. Pensez par exemple aux tests unitaires automatiques et aux outils d’analyse du code statique comme SonarQube pour valider le code en profondeur. Un score est généralement donné sur la base du nombre de bugs, de vulnérabilités, de codes smells, du pourcentage de réussite des tests unitaires, ainsi que du pourcentage de fonctionnalité couvert par les tests unitaires (code coverage). Il s’agit d’un feed-back très important sur lequel il faut immédiatement travailler. Un build qui ne répond pas aux exigences minimales peut être mieux arrêté pour garantir la qualité. Un système CI y contribue étant donné qu’il lance un processus automatique lorsqu’un développeur introduit son code « commit » dans le référentiel source. Le système lance le build et les tests automatiques.
Pour le déploiement de ces artefacts vers les différents systèmes, il y a également toujours des étapes automatiques à parcourir, en fonction de la technologie utilisée. Les systèmes originaires du cloud, comme Kubernetes, sont fondamentalement différents. À l’avenir, le type de pipeline utilisé continuera également d’évoluer. Des systèmes événementiels (Keptn (ketpn.sh) les utilise par exemple) sont déjà en cours d’élaboration et fonctionnent idéalement dans un environnement Kubernetes avec plusieurs centaines de micro-services. Des tests automatiques au cours des différentes phases du deploy pipeline traditionnel doivent également permettre une amélioration implicite et continue de la qualité.
Les tests explicites de performance, réalisés à l’aide de tests de charge/stress, font également partie intégrante du pipeline automatique. Les environnements sont également surveillés sur ce point. Cela se fait au niveau du système, mais surtout au niveau des applications (observabilité) et même au niveau des utilisateurs (real user monitoring). L’utilisation d’un système tel que Dynatrace dans les environnements inférieurs (TEST, INT, ACC...) permet d’examiner de l’intérieur les informations qui accompagnent toutes sortes de tests. Cela permet de gagner un temps précieux lors de la résolution de bugs et, implicitement, d’améliorer la qualité.
En outre, les tests manuels sont et restent extrêmement importants. Dans une équipe multidisciplinaire, on retrouve donc idéalement aussi des personnes ayant des compétences en testing. En même temps, il est très intéressant pour certaines organisations de mettre en place le test management et le coaching de manière transversale. La sécurité est également un thème clé, elle doit être intégrée dans une certaine mesure dans une équipe, mais elle peut aussi parfaitement être facilitée de manière transversale.
L’objectif final de tous ces tests est bien entendu d'aboutir à un ensemble techniquement efficace, mais il ne faut pas non plus perdre de vue la valeur visée et l’utilité pratique. Avons-nous construit quelque chose qui corresponde aux attentes initiales ? Les user stories se retrouvent-elles dans le résultat ? Ces boucles de feed-back sont très importantes et caractéristiques d’une manière agile de créer de la valeur.
(1) artefact binaire : du code au langage machine, afin qu’il puisse être exécuté par une machine
Cet article fait partie d’une série de blogs consacrés à tous les éléments importants d’un processus de développement Agile. Lisez également ce qui suit :