Avantika Mathur, chef de produit chez Electric Cloud, a parlé pendant Continuous Lifecycle London qui a eu lieu le mois dernier, des coûts associés à un nombre toujours croissant de scripts dans un Pipeline de Livraison Continue. Outre le coût de la maintenance, le manque de visibilité et d'auditabilité sur les activités qui sont exactement menées avant de déployer un changement en production représente un coût important dont peu d'organisations sont conscientes.
La résolution de ce problème nécessite d'abord de reconnaître les problèmes et d'établir des principes directeurs pour une nouvelle approche de l'orchestration de pipeline. Mathur recommande ces principes comme point de départ :
- Assurer la répétabilité et la cohérence entre les déploiements.
- Séparer les définitions d'application de l'environnement(s) où il sera déployé/exécuté.
- Viser la portabilité entre les environnements.
- Éviter le verrouillage de certains outils et de la technologie (en d'autres termes, s'assurer que les pratiques guident le travail, plutôt que les outils).
Pour ce qui est de s'éloigner de l'étalement des scripts, l'approche proposée par Mathur consiste à refactoriser les scripts en fonctions communes paramétrées et à les remplacer plus tard - si possible - par des outils capables de faire le même travail, voire mieux.
Cependant, s'attaquer à un grand nombre de scripts à la fois peut être difficile (du point de vue technique et du point de vue des gens) et inefficace (en se concentrant d'abord sur un faible ROI). Mathur recommande une approche itérative. Tout d'abord, exécutez des exercices de cartographie des flux de valeur pour identifier les goulots d'étranglement et les dépendances qui ralentissent la livraison et/ou obscurcissent le processus de livraison. Cela aidera à prioriser les scripts qui doivent être refactorisés en premier. Mathur a également suggéré de catégoriser les scripts existants en buckets (configuration, déploiement, automatisation des tests, etc.) pour identifier les tâches en double, les classer en termes de complexité pour estimer l'effort, mesurer la fréquence d'exécution du script et enfin vérifier s'il y a une meilleure alternative (pas maison) pour minimiser les coûts.
Mathur a vu de ses propres yeux les effets de ces « cauchemars scripturaux », puisque 80% du temps d'ingénierie d'une équipe est consacré à leur maintenance (pas à l'évolution) ou à des scripts qui automatisent simplement des processus lents et inefficaces. Les « odeurs » typiques qui indiquent que les scripts sont hors de contrôle et que l'orchestration des pipelines est insuffisamment prise en compte comprennent des ingénieurs dédiés au maintien des scripts, la peur de modifier les scripts fragiles, le manque de visibilité sur les opérations exécutées.
En bref, Mathur recommande de « traiter le pipeline comme un produit », en veillant à ce que chaque modification du pipeline soit testée et entièrement vérifiée avant la « production » (c'est-à-dire accessible à tous en ingénierie). Cela signifie également rendre le pipeline visible pour tous, mesurer et améliorer les performances à l'aide de mesures et de benchmarks, et réutiliser autant que possible les pièces existantes.