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...
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.