Qu'est-ce que DevOps et ce qu'il n'est pas ?

De Wiki Agile du @GroupeCESI
Aller à : navigation, rechercher

Auteur : Alan Koch
Source : What DevOps Is and What It Is Not DZone - DevOps Zone)
Date : 02/03/2017


Traducteur : Jean-Guy Lapierre
Date : 02/04/2017


Traduction :

DevOps est difficile à définir parce que sa façon de fonctionner est différente pour les différents rôles TI et parce qu’il existe plusieurs fausses idées à son sujet.

The DevOps Zone vous est proposée en partenariat avec Sonatype Nexus. La Nexus Suite permet d'optimiser la livraison de DevOps grâce à l'intégration continue d'intelligence de composant intégrée dans les outils de développement, y compris Eclipse, IntelliJ, Jenkins, Bamboo, SonarQube et plus encore. Planifiez une démonstration aujourd'hui.

DevOps n’est pas facile à définir. Cela est vrai pour quelques raisons. Ce à quoi il ressemble et comment il fonctionne apparaît différent selon les différentes perspectives de la variété de rôles TI. DevOps affecte tout le monde en TI, mais il affect chacun des rôles de différentes façons ce qui génère différentes descriptions.

Ce que n’est pas DevOps

Il est également difficile à définir parce qu’il y a tellement de fausses idées à son sujet. Alors, avant d’essayer de définir DevOps, prenons quelques minutes pour abattre les idées fausses les plus répandues.

DevOps n’est pas un nouvel outil

Alors même que la communauté DevOps a créé plusieurs nouveaux outils et que plusieurs des choses recommandées par DevOps ne peuvent être faites sans outils. Utiliser Puppet, Docker, Jenkins ou autres outils ne signifie pas que vous « faites du DevOps ».

DevOps n’est pas une nouvelle équipe

Le nom "DevOps" implique la connexion des parties développement (Dev) et opérations (Ops) de l'informatique. Ajouté un autre groupe entre Dev et Ops serait contre-productif pour atteindre cette fin. La création d'une équipe DevOps pour expérimenter les processus, les outils et recommander la façon dont Dev et Ops devraient fonctionner ensemble est une excellente façon de démarrer - tant que cette équipe est constituée de Dev et Ops, et qu’elle ne se positionne pas entre elles.

DevOps n’est pas un nouveau rôle

De nombreuses entreprises sont à la recherche « d’ingénieurs DevOps », démontrant qu'elles ne comprennent pas ce qu'elles demandent. DevOps englobe tout ce qui se passe dans une organisation informatique. Un « ingénieur DevOps » serait un homme-orchestre des TI faisant tout. Tout!

DevOps n’est pas un référentiel de connaissances

Il n’y a pas d’autorité centrale ni de normes DevOps. Il n’y a pas qu’une seule « bonne manière » de suivre le chemin du DevOps.

Ce qu’est DevOps

“The DevOps Handbook” Gene Kim, et. al, dit :
DevOps et les pratiques techniques, architecturales et culturelles résultantes représentent une convergence de nombreux mouvements philosophiques et de gestion (incluant) :le Lean management, la Théorie des contraintes, le système de production Toyota, l’ingénierie de résilience, les organisations apprenantes, la culture de la sécurité, des facteurs humains, les cultures de gestion de haute confiance, le Servant leadership, la gestion du changement organisationnel et les méthodes Agiles.

En d’autres mots, DevOps c’es une manière de concevoir les bonnes pratiques de plusieurs domaines différents et de les implanter dans une organisation TI pour améliorer la performance des TI.

Bien que DevOps s'appuie sur certaines disciplines très bien établies, le mouvement DevOps lui-même est assez récent. Le terme «DevOps» a vu le jour à la fin de 2009, marquant le début de ce mouvement à forte croissance. Comparez ceci avec le terme "Agile", qui a été inventé au début de 2001 - ce qui a amené le mouvement Agile plus de deux fois plus vieux.

La jeunesse de ce mouvement est une autre raison pour laquelle DevOps est si difficile à définir. La communauté DevOps a rapidement grandi et a appris. Les pratiques évoluent, les outils continuent d’évoluer vers plus de maturité et toutes les organisations qui se sont jointes au mouvement ont contribué à notre connaissance de DevOps.

Les trois voies de Gene Kim

Gene Kim a été une voix prédominante décrivant DevOps à travers la courte histoire de ce mouvement. Son roman de 2013, Le projet Phoenix décrit une organisation informatique fictive et son utilisation des principes DevOps pour résoudre quelques problèmes sérieux. Son livre de 2016 The DevOps Handbook fournit des conseils détaillés pour toute organisation qui se lance dans une transformation DevOps, en se basant sur l'expérience de centaines d'autres organisations qui ont déjà parcouru cette route.
Ces deux livres sont basés et structurés autour de ses «trois voies». Les trois voies de Gene Kim sont les principaux éléments d'un parcours DevOps et constituent une sorte de feuille de route pour la compréhension et la mise en œuvre de DevOps. Ce sont:

  1. Flux
  2. Rétroaction
  3. Formation continue

La première voie : Flux

DevOps-Flux.jpg
La première voie consiste à se concentrer sur le flux d'activité dans votre organisation TI et à optimiser pour que cela se déroule doucement et rapidement. L'un des principaux flux dont nous devons nous charger est le flux de la valeur (sous la forme de solution informatique) de nos équipes de développement jusqu’à l’utilisation opérationnelle en production. Cela implique des concepts comme la livraison continue et l'optimisation de votre pipeline de déploiement.
Pour le dire en termes Lean, la première voie consiste à comprendre votre «flux de valeur», à identifier et à éliminer les obstacles à un flux fluide et à automatiser pour augmenter la vélocité de ce flux.

La deuxième voie : Rétroaction

DevOps-Rétroactions.jpg
La deuxième voie s’appuie sur la première en optimisant le flux de retour de droite à gauche. Cela inclut les rétroactions finales: les équipes de développement ont une vision approfondie de la performance de leur logiciel et de la manière dont ils sont utilisés par les utilisateurs finaux. Cela comprend également tous les types de rétroactions de toutes les personnes dans tous les rôles sur le chemin.
L’intention de la deuxième voie est de fournir une visibilité claire aux personnes qui ont a réaliser une tâche sur la qualité de leur travail et sur les répercussions qu'elles ont sur les autres, tant au plan TI que sur ceux des clients, des utilisateurs et de l'organisation en général. Cela inclut non seulement d’assurer que les rétroactions sont fournies, mais aussi de raccourcir et d’optimiser les boucles de rétroaction afin que les personnes reçoivent ces commentaires aussi rapidement et aussi automatiquement que possible.

La troisième voie : Formation continue

Devops-Formation continue.jpg
Avec un flux et un système de rétroaction bien établis, la troisième voie capitalise pour établir les patterns d'apprentissage continu et d'amélioration continue.
Elle soulève des questions comme «Qu'est-ce qu'on peut apprendre de ce que nous avons fait et des rétroactions que nous avons reçues?» Et «Comment pouvons-nous utiliser ces connaissances pour améliorer les performances de l'organisation TI?

En fin de compte, cet apprentissage dépasse les bases de nos pratiques et comprend des expérimentations pour trouver de nouveaux moyens novateurs pour mieux répondre aux besoins de nos clients, de nos utilisateurs et de l'organisation. Par exemple, avec HDD (Hypothesis-Driven Development), nous posons des hypothèses sur les capacités logicielles dont nos utilisateurs et nos clients pourraient avoir besoin, puis menons des expériences pour tester ces hypothèses, pour rejeter les expériences qui échouent et s'appuyer sur celles qui fonctionnent.

La troisième voie implique une transformation culturelle dans notre approche de l'échec: une volonté de percevoir l'échec comme une opportunité d'apprentissage! Qu'il s'agisse d'une défaillance opérationnelle inattendue ou du résultat d’une expérience, nous considérons le bon côté de l'échec parce que nous en apprenons quelque chose et cela permet de nous améliorer.

Automatiser tout ce que vous pouvez

Un principe clé du DevOps est «d’automatiser tout ce que vous pouvez». Ce principe est important, car l'automatisation est centrale à la capacité d'une équipe informatique d’optimiser le flux (la première voie), les boucles de rétroaction rapide (la deuxième voie) et les performances élevées. Car l'apprentissage continu et l'amélioration continue de la troisième voie donnent des fruits). L'automatisation sous-tend la performance DevOps en une série de façons:

  • Vélocité accrue. Les activités automatisées sont plus rapides que celles qui sont manuelles. Si une activité peut être automatisée, il n'y a aucun moyen pour une personne de le faire plus rapidement.
  • Réduction de l'erreur humaine. Les outils ne commettent pas d’erreurs comme les personnes le font. Une fois qu'un outil a été correctement configuré et vérifié, il fonctionnera correctement à chaque fois.
  • Consistance. Tout ce qui est réalisé par un outil sera cohérent par définition. Les outils peuvent être utilisés pour vérifier et renforcer la cohérence des activités qui ne sont pas automatisées.
  • Risque atténué. Parce que les outils ne font pas d’erreurs et qu’ils sont utilisés pour vérifier les activités manuelles, ils peuvent être déployés pour atténuer les risques qui ne peuvent être évités.

Les organisations performantes automatisent tout ce qu'elles peuvent; c’est ainsi qu'ils deviennent des organisations performantes.

DevOps résout le conflit de base chronique

Chaque organisation TI a deux priorités simultanées:

  1. Innovation. Respecter les besoins changeants de nos clients et de nos utilisateurs en développant et en déployant des services et des applications informatiques nouveaux et améliorés.
  2. Stabilité. Assurer que nos clients et nos utilisateurs peuvent utiliser ces services et applications TI et que leurs données et informations sont sécurisées.


Ces deux priorités sont en conflit l’une avec l’autre, car le déploiement de changements dans l'environnement de production est la cause la plus fréquente des pannes et des autres problèmes opérationnels. Pire encore, ces priorités contradictoires causent des frottements et d'autres dysfonctionnements au sein des organisations TI, car le développement détient généralement la priorité de l'innovation, tandis que les opérations celle de la stabilité.

DevOps ne dit pas seulement que Dev et Ops (et AQ et Sécurité) doivent collaborer. Il résout également ce « conflit chronique de base » en permettant l'innovation et la stabilité en même temps. Les pratiques et les outils de DevOps garantissent la stabilité et la prévisibilité de l'ensemble des opérations TI, en se centrant particulièrement sur la stabilité durant le processus d'innovation et de déploiement. Cela accélère l'innovation en permettant aux équipes TI d’agir rapidement et de les déployer fréquemment sans mettre en danger la sécurité et la stabilité.

Utiliser ce que nous savons

Votre organisation TI est déjà dans la première étape (au moins) du parcours DevOps car DevOps ne signifie pas de tout balancer et de refaire. Cela signifie plutôt d’observer comment vous faites ce que vous faites et d’utiliser des outils et des techniques particulières pour faire fonctionner le flux, améliorer les rétroactions et commencer à apprendre et à améliorer en continu.
Identifiez ce qui fait mal, découvrez comment les autres ont résolu ce problème et amélioré. Voilà! Vous êtes sur votre parcours DevOps.
The DevOps Zone vous est proposée en partenariat avec Sonatype Nexus. Utilisez Nexus Suite pour automatiser votre chaîne de livraison logicielle et assurez-vous d'utiliser les composants « open source » de la plus haute qualité à chaque étape du cycle de développement. Obtenez Nexus aujourd'hui.