Afficher l'état du pipeline

Définition du statut des pipelines

Dans une équipe DevOps, les actions de compilation, d'intégration, de test et de déploiement sont matérialisées par un pipeline de mise à jour dont certaines étapes peuvent rester manuelles pendant un certain temps. Au-delà des points techniques liés à l'automatisation, un pipeline pose souvent la question de l'automatisation du déploiement lors de sa mise en place. En effet, si la mission des Développeurs est de créer de la valeur ajoutée et idéalement de l'innovation, les Opérations doivent fournir un environnement stable aux Clients. Cette différence de point de vue est appelée le "mur de la confusion" [Kawaguchi 2020] et une culture DevOps doit être instaurée dans l'équipe pour résoudre ce conflit. Pour ce faire, le pipeline doit avoir des étapes d'assemblage, de libération et d'exécution distinctes afin de maximiser la déployabilité et de rassurer les équipes les plus méfiantes [Wiggins 2017].
La séparation des étapes donne à la fois la transparence nécessaire à l'acceptation de chaque étape, mais aussi une bonne modularité des activités de livraison pour rationaliser ces activités et mieux orchestrer les livraisons. De plus, lorsque l'état du pipeline est représenté en fonction de chaque étape avec celle qui serait bloquée, c'est un excellent Andon pour mobiliser les équipes autour de la santé du processus de déploiement [Larman 2010] [Humble 2011].

La visualisation du pipeline et de son historique améliore la transparence du processus de livraison. Plus le processus est visible, plus les parties prenantes peuvent collaborer autour de la livraison, plus le flux de livraison peut être fluide [Kotter 2014] et avec une confiance accrue dans ce qui est envoyé en production. Cette confiance favorise ensuite l'automatisation des opérations de déploiement. C'est dans cette perspective collaborative que le concept de ChatOps a été créé. Le terme serait dû à Jesse Newland, mais son origine remonterait à 2008 chez GitHub [Moustier 2020]. ChatOps rend visible le travail collectif et les discussions autour des actions lancées aux bots [Kim 2016] [Moustier 2020].

Influence sur la maturité des tests

La composante de partage dans DevOps est essentielle, c'est pourquoi on la retrouve dans certaines définitions de DevOps [Buchanan 2021]. En termes de pratique, ce partage peut commencer simplement avec des développeurs orientés X-Team, mais ce qui est visé par la création d'équipes DevOps est la fusion de l'écocycle Dev avec l'écocycle Ops ; le pont construit par une orientation X-Team est une première étape dans cette fusion des activités.

‍

La mise en œuvre de ce pipeline se fait autour d'un projet pilote avec une définition minimaliste du pipeline. Les développeurs commencent souvent à automatiser le processus de livraison et intègrent progressivement des éléments de la culture Ops qui sont progressivement automatisés par les développeurs. Plus les développeurs se familiarisent avec les préoccupations des Ops, plus ils y prêtent attention et y participent. Une façon complémentaire de faire croître le pipeline est d'utiliser la technique du Value Stream Mapping (VSM) [Rother 1999]. Cette cartographie consiste à prendre des mesures sur chaque étape du pipeline et à utiliser ces valeurs pour identifier où optimiser le processus de livraison. SAFe propose trois valeurs [Martin 2014] :

• Process Time (PT) : il s'agit du temps passé à mettre en œuvre la solution.
• Lead Time (LT) : c'est le temps de traitement et d'attente entre les processus.
• Pourcentage de données complètes et exactes (%C&A)

Il est alors possible d'identifier les étapes à améliorer là où cela semble nécessaire, sachant que les actions peuvent être classées selon plusieurs catégories [Monden 1994] :

• celles qui doivent être éliminées, car elles n'apportent aucune valeur ajoutée ("opérations sans valeur ajoutée" - NVA)
• celles qui consomment de l'énergie mais sont nécessaires ("Necessary but Non-Value Adding operations" - NNVA)
• celles qui transforment la matière première en valeur ajoutée pour le client ("opérations à valeur ajoutée" - VA)

Selon cette classification, l'objectif est d'éliminer les actions qui n'apportent pas de valeur ajoutée et ne sont pas nécessaires, mais aussi d'identifier les éventuels goulets d'étranglement selon la théorie des contraintes.

‍

Le point de vue d'Agilitest sur cette pratique

Agilitest peut être facilement intégré notamment à Jenkins, GitLab ou Azure pipeline en tant qu'orchestrateur de pipeline. Tous ces orchestrateurs fournissent un retour visuel sur le processus de livraison.

Il est à noter que les tests de systèmes à partir d'interfaces graphiques (GUI) sont sujets à un faible temps de réponse ; il est donc recommandé de dissocier les lancements de pipeline de livraison basés sur les commits de code des tests scripts GUI, surtout lorsqu'une certaine quantité de scripts est mise à disposition.

Avoir une politique de pipeline multiple est fait pour éviter que les développeurs subissent des commits de longue durée [Rady 2011] [Larman 2010] [Ambler 2012] [Humble 2011]. En effet, lorsque les commits durent plus de 10 minutes, les développeurs font moins de commits, ce qui augmente le temps d'intégration et les problèmes de flux. Cette politique devient beaucoup plus critique lorsque le pipeline intègre plusieurs types de tests, puisque certains d'entre eux peuvent durer plusieurs heures, voire plusieurs jours...

‍

Pour découvrir l'ensemble des pratiques, cliquez ici.

‍