La paternité du terme DevOps revient à un Belge du nom de Patrick Debois autour de 2009. Faisant suite à une frustration croissante lors de ses missions pour le compte du gouvernement belge à propos des conflits entre développeurs et administrateurs système. Historiquement, les DSI séparent les équipes de développement des équipes d'exploitation du SI (Operations en anglais d'où le Ops). Ces équipes ont des intérêts divergents, les développeurs souhaitent du changement (nouvelles technologies, nouvelles pratiques, etc.) et les opérationnels souhaitent de la stabilité puisque le bon fonctionnement du SI est sous leur responsabilité.
L'objectif de ce mouvement, identifié également comme un courant de pensée ou une culture, est de faire tomber les barrières pour fluidifier l'évolution du SI. De manière générale, DevOps est une approche qui repose sur les principes Lean et Agile dans lesquels les responsables métier avec les services de développement, des opérations et d'assurance qualité collaborent pour délivrer le logiciel en continu dans l'objectif de permettre à l'entreprise de saisir plus rapidement les opportunités du marché et d'accélérer la prise en compte des retours clients. En effet, les applications d'entreprise sont si diverses et composées de tant de technologies, bases de données, d'équipements utilisateurs, etc., que seule une approche DevOps permet de gérer avec succès toute cette complexité. Cependant, les opinions sur son utilisation divergent.
Depuis l'avènement du cloud la sécurité est devenue également un sujet majeur, on voit désormais aussi apparaître le terme de DevSecOps pour placer la sécurité informatique au cœur des évolutions du SI.
La société Puppet, qui propose un outil du même nom permettant de gérer les configurations de systèmes de manière déclarative (on parle d'Infrastructure As Code), publie chaque année les résultats d'une enquête cherchant à mieux comprendre l'évolution de la culture DevOps au sein des organisations. L’entreprise a livré l’édition 2020 de son rapport State of DevOps, le neuvième à son actif. Dans son enquête, Puppet s’est intéressé à deux évolutions structurelles qui peuvent constituer des pistes de réflexion pour les entreprises souhaitant avoir de bons résultats en la matière :
- La première porte sur le modèle de plateforme, une approche relativement nouvelle pour donner plus d’outils aux équipes de développement d'application. Selon Puppet, lorsque cette approche est menée correctement, cela se traduit par une livraison plus rapide et plus efficace de logiciels de haute qualité qui répondent aux besoins commerciaux d’une organisation et à grande échelle.
- La seconde concerne l’application des principes DevOps à la gestion du changement. Selon Puppet, la gestion du changement est un goulot d'étranglement courant qui empêche la publication de logiciels à un rythme qui permet à l'entreprise d'atteindre ses objectifs. Une gestion des changements efficace et efficiente améliore la capacité d’une organisation à publier des logiciels dans les délais, au niveau de qualité et de sécurité requis par l’entreprise.
« Au fil des ans, nous avons montré que les pratiques DevOps conduisaient à de meilleures performances et résultats organisationnels. Nous avons appris et partagé les pratiques et les modèles qui permettent aux organisations d'évoluer et de publier de meilleurs logiciels plus rapidement. Malgré les progrès notables dont nous avons été témoins, nous avons également constaté que la plupart des organisations ont du mal à dépasser les étapes intermédiaires de leur évolution DevOps. Ils sont rarement en mesure de faire évoluer les méthodes de travail DevOps au-delà des équipes de développement, d'exploitation et (parfois) de sécurité. Pourtant, certaines organisations réussissent. Ils étendent les pratiques DevOps au-delà des équipes initiales d'adoption précoce, en continuant d'évoluer et de s'améliorer dans toute l'organisation. Qu'est-ce qui fait la différence ? Les organisations qui réussissent adoptent des changements structurels plus profonds.
« L’enquête DevOps de cette année a montré deux domaines de changement structurel qui peuvent donner d’excellents résultats: une approche de plateforme pour la livraison de logiciels et l’application des principes DevOps à la gestion du changement. Lorsque les organisations réussissent à établir un modèle de plateforme pour permettre le développement d'applications ou à améliorer considérablement l'efficacité de leur gestion du changement, elles atteignent l'objectif visé par les initiatives DevOps : une livraison plus rapide et plus facile de logiciels de meilleure qualité et plus sécurisés ».
Les 5 étapes d'un modèle d'évolution DevOps
Puppet rappelle que DevOps consiste fondamentalement à permettre aux gens de collaborer les uns avec les autres vers un objectif commercial commun. Cela inclut nécessairement les processus et les outils utilisés par les équipes, mais la conversation passe souvent sous silence les problèmes structurels au sein d'une organisation qui empêchent une bonne communication, la libre circulation du travail et l'amélioration continue.
« Bien que les pratiques DevOps soient bien comprises et bien adoptées une décennie après le début du mouvement, nous constatons toujours que la plupart des organisations ont du mal à étendre DevOps au-delà de quelques poches de succès. L'une des raisons pour lesquelles DevOps ne parvient souvent pas à se développer davantage est que la plupart des entreprises sont structurées de manière à créer des incitations mal alignées et un manque de responsabilité ou d'appropriation des résultats qu'elles sont censés générer ».
Pour Puppet, les équipes qui adoptent à elles seules un ensemble de pratiques ne peuvent pas faire avancer l'évolution DevOps; il est important d'effectuer les changements structurels correspondants pour optimiser le fonctionnement des équipes. Aussi, le rapport indique les cinq étapes d'un modèle d'évolution DevOps.
Étape 0 : bâtir les fondations
Cette première étape numérotée zéro ne fait pas à proprement parler des étapes identifiées, elle ne compte pas dans les 5.
Elle référence les pratiques nécessaires à l'évolution vers les autres étapes. Ces pratiques doivent perdurer dans le temps pour permettre la continuité de l'évolution et même son maintien.
- Les systèmes de supervision et d'alertes sont configurables et à la main des équipes opérant le service.
- Les modèles de déploiement pour construire (build) les applications ou les services sont réutilisés.
- Les modèles de test (tout type de tests) pour construire les applications ou les services sont réutilisés.
- Les équipes contribuent à l'amélioration des outils proposés par les autres équipes.
- Les configurations sont gérées par un outil de gestion de configuration (Un SCM : SVN, git, bitbucket...).
Étape 1: normaliser la pile technologique
À cette étape, les équipes de développement tentent de se coordonner pour utiliser plus de pratiques agiles.
Pratiques clés :
- Les équipes de développement utilisent un outil de contrôle de version (SVN, git, bitbucket...)
- Les équipes de développement déploient sur un éventail d'OS standardisés.
Pratiques contribuant au succès
- Bâtir sur un éventail standardisé de technologies.
- La configuration des applications est versionnée.
- Les changements dans l'infrastructure sont testés avant d'arriver en production.
- Les codes sources de tous les outils et applications sont libres d'accès pour toutes les équipes.
Étape 2 : standardiser et réduire la variance
À cette étape les équipes Dev et Ops se concentrent sur l'homogénéisation du SI.
Par exemple un seul système (ou famille de système), nombre de langages limités, etc.
L'objectif est de réduire la complexité du SI.
Pratiques clés :
- Utiliser un jeu standard de technologies.
- Les équipes déploient sur un OS unique.
Pratiques contribuant au succès :
- Les modèles de déploiement pour construire (build) les applications et les services sont réutilisés.
- Les applications sont réarchitecturées pour correspondre aux besoins métiers.
- Les configurations système sont versionnées comme les applications.
Étape 3 : montée en puissance des pratiques DevOps
À ce stade, la réutilisation des processus de build et le test de l'infrastructure sont maîtrisés complètement.
Les pratiques DevOps se répandent dans l'organisation, la collaboration augmente.
La complexité administrative pour effectuer des changements est réduite en donnant plus de pouvoir aux techniciens.
Pratiques clés :
- Les personnels peuvent travailler sans recourir à des autorisations manuelles extérieures à l'équipe.
- Les modèles de déploiement pour construire (build) les applications et les services sont réutilisés.
Pratiques contribuant au succès :
- Les personnels peuvent effectuer des changements sans temps d'attente.
- Les changements dans les services peuvent avoir lieu en pleine journée de travail.
- Les retours d'expérience post-incidents et les statistiques associées sont publics et partagés.
- Les équipes travaillent sur des technologies standardisées.
- Les équipes utilisent de l'intégration continue.
- Les équipes gérant l'infrastructure utilisent le contrôle de version.
Étape 4 : automatisation de la livraison de l'infrastructure
Cette étape est définie par l'automatisation de la configuration des systèmes et de leur livraison (le provisioning).
L'automatisation poussée permet aux opérationnels de livrer aux développeurs et à la QA (les services de testeurs) des environnements conformes à ce qu'ils ont en production.
L'automatisation permet également de dégager du temps pour développer le self-service, permettant aux développeurs et à la QA de commencer à générer eux-mêmes leurs environnements.
Pratiques clés :
- Les configurations système sont automatisées.
- La livraison des systèmes est automatisée.
Pratiques contribuant au succès :
- Les configurations de politiques de sécurités sont automatisées.
- Les ressources sont mises à disposition en self-service.
Étape 5 : fournir des capacités de self-service
À cette étape, les équipes de développement sont libérées des contraintes administratives et des temps d'attente pour obtenir les outils nécessaires à leur travail, elles n'ont qu'à se servir elles-mêmes.
Pratiques clés :
- La réponse aux incidents est automatisée.
- Les ressources sont disponibles en self-service.
Pratiques contribuant au succès :
- Les configurations de politiques de sécurités sont automatisées.
- Les développeurs déploient leurs environnements de tests par eux-mêmes.
- Les métriques des projets sont visibles.
- Le provisioning est automatisé.
« C'est ce que signifie faire évoluer les pratiques DevOps : en permettant aux individus et aux équipes de s'appuyer sur leurs connaissances et leur expérience – et en automatisant – vous êtes en mesure d'optimiser à l'échelle de l'organisation. Vous êtes désormais en mesure de vous concentrer sur l'élimination des déchets dans plusieurs flux de livraison et d'aider l'entreprise à atteindre ses objectifs ».
Modèle de plateforme : une nouvelle approche de la mise à l'échelle DevOps
« Tout se passe bien quand votre entreprise ne dispose que d'un ou de quelques produits seulement. Mais si vous avez une centaine de produits ou de services, dédier une équipe à chaque produit ou service serait à la fois inefficace et onéreux. 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 maintenant leur infrastructure et plus encore. C’est du temps qu’il serait préférable de consacrer à la création et à l’amélioration des produits dont vos équipes sont responsables ».
Le manque de technologies et de processus normalisés crée également d'autres problèmes:
- La gouvernance devient coûteuse et presque impossible à gérer.
- Des piles séparées réduisent le partage des connaissances au sein de l'organisation.
- Nombre de vos équipes produit n’ont pas les compétences ou l’expertise nécessaires pour exploiter une infrastructure complète et une pile d’applications. De nombreux développeurs considèrent les opérations d'infrastructure comme une distraction par rapport à leur travail réel, ils ne s'y concentrent donc jamais vraiment.
« Bien que le fait de disposer de plusieurs équipes de produits de bout en bout ne s'adapte pas bien à de grands environnements complexes, un modèle de plateforme défini par un objectif, des limites et des responsabilités clairs le fait. Une plateforme, conçue en pensant au client, peut réduire considérablement le travail et les frais généraux des équipes produit individuelles.
« De manière générale, l'équipe de la plateforme fournit l'infrastructure, les environnements, les pipelines de déploiement et d'autres services internes qui permettent aux clients internes - généralement des équipes de développement d'applications - de créer, déployer et exécuter leurs applications ».
Si le modèle de plateforme est une approche souvent associée aux environnements natifs cloud, Puppet y voit plusieurs avantages pour plusieurs autres types d'architectures, notamment :
- Les équipes d'application peuvent être plus efficaces. Elles n'ont pas besoin d'être des expertes en opérations d'infrastructure ou d'avoir une connaissance approfondie de chaque outil de la chaîne d'outils, elles peuvent donc se concentrer sur le produit. Les développeurs d'applications n'ont plus besoin d'attendre une équipe centralisée pour leur fournir des environnements de test ou des ressources cloud, et leur autonomie qui en résulte leur permet de travailler beaucoup plus rapidement
- La gouvernance est améliorée. Vous ne pouvez pas gérer efficacement les coûts, la conformité et l’audit si toutes vos applications s’exécutent sur des piles d’infrastructure entièrement différentes, en utilisant des processus différents. Une plateforme efficace permet une gouvernance informatique efficace tout en permettant aux équipes d'application de livrer rapidement
- La fin du changement de contexte. Changer constamment d'attention entre une application et les opérations d'infrastructure est une énorme perte de productivité (et de créativité aussi). Les travailleurs individuels et les équipes sont mieux lotis lorsqu'ils peuvent se concentrer sur leur propre contexte particulier. Pour une analyse plus approfondie de ces deux contextes différents et de la manière dont les équipes interagissent, consultez la barre latérale à droite, Plateforme et application: deux contextes différents.
- Amélioration continue des infrastructures. Une plateforme commune qui offre des solutions orientées client plutôt qu'un accès brut à l'infrastructure donne à votre organisation plus de flexibilité. Les consommateurs de la plateforme ne sont pas liés à des implémentations spécifiques de votre pile d'infrastructure, de sorte que l'équipe de la plateforme peut remplacer et mettre à niveau des composants de manière itérative et n'a besoin d'interagir que de manière minimale avec les équipes d'application.
La situation du panel
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.
Évolution DevOps et efficacité de la gestion du changement
Selon les conclusions du sondage, l'efficacité de la gestion du changement augmente à mesure que les organisations font évoluer leurs pratiques DevOps. Les entreprises très évoluées sont presque trois fois plus susceptibles d'avoir une gestion du changement très efficace que les entreprises à un faible niveau d'évolution DevOps.
La gestion du changement la plus efficace est réalisée par les entreprises qui mettent l'accent sur:
- Un degré élevé d'automatisation des tests et du déploiement.
- Un degré élevé d'atténuation automatisée des risques.
- Processus d'approbation moins rigides et beaucoup moins manuels.
- Écriture des modifications de code.
- Donner aux employés plus de latitude pour influencer la gestion du changement.
- Processus et culture DevOps.
Les processus d'approbation très orthodoxes rendent le processus de gestion du changement inefficace. Les entreprises avec des approbations très orthodoxes sont neuf fois plus susceptibles d'avoir des niveaux élevés d'inefficacité dans leur processus de gestion du changement que les entreprises avec de faibles niveaux d'approbation orthodoxe.
L'automatisation rend les gens plus confiants que leur gestion du changement est efficace. Les entreprises dont les employés pensent que leur gestion du changement est efficace sont trois fois plus susceptibles d'automatiser les tests et le déploiement que les entreprises où la confiance dans les performances de gestion du changement est faible.
Les entreprises qui donnent aux gens leur mot à dire dans le processus de gestion du changement ont une meilleure gestion du changement.
- Les entreprises qui ont une forte implication des employés dans le processus de gestion du changement sont plus de cinq fois plus susceptibles d'avoir une gestion du changement très efficace que les entreprises à faible implication des employés.
- Les entreprises qui se concentrent le plus sur l'automatisation impliquent également le plus leurs employés dans leur processus de gestion du changement.
- Les entreprises qui ont le processus le plus lourd et le plus manuel impliquent le moins leurs employés dans leur processus de gestion du changement.
Source : 2020 State of DevOps Report
Et vous ?
Que pensez-vous du DevOps dans l'absolu ? Que pensez-vous de l'approche consistant à proposer une plateforme interne qui fournit l'infrastructure, les environnements, les pipelines de déploiement et d'autres services internes qui permettent aux clients internes (généralement des équipes de développement d'applications) de créer, déployer et exécuter leurs applications ? Votre entreprise en dispose-t-elle ?