Puppet vient de livrer son rapport 2020 State of DevOps, 9ème du genre, qui s’appuie sur les réponses de 2 400 professionnels de l’IT, du développement et de la sécurité dans le monde. Cette année, l’enquête a montré deux évolutions structurelles qui peuvent donner de bons résultats, expliquent ses auteurs. La première porte sur l'approche plateforme de la livraison de logiciels, relativement nouvelle. Elle peut déboucher sur des logiciels de plus grande qualité livrés plus vite, de façon plus efficace, en répondant à l’échelle aux besoins des entreprises. La deuxième évolution concerne l’application des principes devops à la gestion des changements. La prendre en compte peut améliorer la capacité de respecter les plannings de livraison et la qualité.

La démarche Devops consiste à permettre une collaboration entre les développeurs et les équipes IT opérationnelles pour atteindre un but métier commun. Elle vise à réduire les problèmes de communication et faciliter le flux de travail et l’amélioration continue. Même si ces pratiques, bien comprises, sont progressivement adoptées depuis dix ans, il y a toujours des organisations qui ont du mal à les mettre en place en dehors de quelques projets réussis. Cela résulte souvent de la façon dont elles sont structurées, faisant apparaître des motivations disparates et la difficulté à rendre des comptes sur les résultats que cette démarche est censée générer.

Le rapport de Puppet rappelle les 5 étapes à mettre en place pour faire évoluer un modèle devops : 1ère étape, la normalisation (utilisation d’un outil de contrôle des versions), 2ème étape, la standardisation (utilisation d’un OS et de technologies standards), 3ème étape, l’expansion (chacun peut travailler sans nécessiter d’une approbation manuelle en dehors de l’équipe, déploiement de modèles pour réutiliser apps et services, les changements sont testés avant leur déploiement en production), 4ème étape, une infrastructure de livraison de logiciels automatisée (sur la configuration de systèmes, le provisioning, la politique de sécurité…), 5ème étape, le self-service (réponses aux incidents automatisés, ressources en self-service…).

Pour 63%, au moins une plateforme interne en self-service

Le modèle de plateforme est censé favoriser une mise à l’échelle de devops. Il fait référence aux équipes produits qui ont popularisé le mouvement devops et qui sont responsables de bout en bout de la livraison d’un produit ou d’un service. « Cela marche très bien quand il n’y a qu’un produit ou quelques-uns seulement. Mais s’il y en a des centaines, dédier une équipe à chaque produit est inefficace et coûteux », note le rapport. « Imaginez 10 équipes ayant chacune sa propre pile technologique, ses outils, ses processus. Chacune essayant de résoudre des problèmes similaires, évaluant des technologies, les intégrant et les maintenant… ». Si les équipes multiples ne conviennent pas aux environnements complexes, un modèle de plateforme peut en revanche réduire significativement les difficultés de chaque équipe. La plateforme fournit l’infrastructure, les environnements, les pipelines de déploiement et les services internes qui permettent aux équipes de développement d’applications de créer, déployer et faire tourner leurs logiciels.

Concernant les pratiques devops déployées à travers des plateformes internes, 63% des répondants ont indiqué que leur entreprise en avait au moins une en self-service et, parmi eux, 60% en ont entre 2 et 4. Pour plus d’un tiers des répondants, 26 à 50% des développeurs utilisent la plateforme interne. Le rapport met en évidence une forte corrélation entre l’utilisation de ces plateformes et la forte évolution devops des entreprises. Les plus évoluées dans ce domaine sont six fois plus nombreuses à y recourir. Par ailleurs, elles sont deux fois plus nombreuses que les moins évoluées à être orientées produits ce qui apparaît comme un point-clé dans la mise à l’échelle de devops. Pour les développeurs, un plus haut niveau d’évolution devops se traduit par davantage d’offres en self-service sur les workflows CI/CD, sur l’infrastructure interne et dans le cloud public, sur les environnements de développement, le monitoring et les alertes, le déploiement de modèles, le provisioning de base de données et l’audit des logs. Dans les entreprises où l’on n’a pas installé de plateforme devops, on invoque en général le manque de temps pour le faire, le manque de standardisation ou de compétences techniques au sein de l’équipe.

Des services consommés à travers des API

Cela dit, indique le rapport Puppet, l’équipe de la plateforme fournie comme un produit n’est pas destinée à être une tour d’ivoire qui prescrit toutes les architectures et outils. Son rôle est de fournir les capacités de base qui facilitent le travail des autres équipes. Sa principale caractéristique est d'apporter des fonctionnalités en self-service qui se consomment à travers des API : l’infrastructure, les environnements de test, les pipelines de déploiement, le monitoring, etc. On peut commencer à la proposer de façon localisée et étendre ensuite son adoption. Sur ce point, les auteurs du rapport insistent sur les qualités d’empathie qui conduisent à comprendre la position de chacun. « Il est impossible de bâtir un bon produit sans empathie pour l’utilisateur », soulignent-ils. Enfin, l’évangélisation est critique au succès de la plateforme fournie comme un produit.

La gestion des changements plus efficace en mode devops avancé

Le deuxième volet du rapport concerne la gestion des changements dans un contexte devops, il s’avère que les entreprises les plus évoluées d’un point de vue devops sont trois fois plus efficaces dans ce domaine que les moins évoluées. La plus grande efficacité est obtenue dans les entreprises qui mettent l’accent sur le niveau élevé de test, d’automatisation du déploiement et de réduction automatisée des risques. Elles ont moins de processus d’approbation manuelle. Les changements sont écrits dans le code et les utilisateurs ont plus de souplesse pour influencer la gestion du changement.

« L’automatisation rend les gens plus confiants que leur gestion du changement sera plus efficace », note les auteurs du rapport Puppet. Les entreprises où les employés le pensent sont trois fois plus enclines à automatiser le test et le déploiement que celles ou la confiance dans le change management est faible. Les principales difficultés pour automatiser les processus de gestion du changement sont la couverture incomplète du test et l’état d’esprit organisationnel. S’y ajoute une architecture logicielle étroitement couplée.

Intégrer la sécurité au processus de delivery

Le rapport de Puppet aborde aussi l’intégration de la sécurité dans le processus de livraison des logiciels. L’intégrer complètement améliore la capacité à remédier plus rapidement aux failles critiques. 45% des entreprises ayant réalisé cette intégration de façon complète peuvent le faire dans la journée. Seules 25% des entreprises ne l’ayant pas intégré peuvent intervenir sur les failles dans la journée.