Les équipes DevOps se tournent de plus en plus vers une approche où les services qui leur permettent de créer et déployer leurs apps sont fournis en interne

Selon l'édition 2020 du State of DevOps

Les équipes DevOps se tournent de plus en plus vers une approche où les services qui leur permettent de créer et déployer leurs applications sont fournis en interne,
selon l'édition 2020 du State of DevOps

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 :...