Devops

Un article de Wikipédia, l'encyclopédie libre.
Aller à : navigation, rechercher

Devops est un mouvement visant à l'alignement de l'ensemble des équipes du système d'information, composé par la réunion des "dev" ou "Dev engineers" chargés de faire évoluer le système d'information et les "ops" ou "Ops engineers" chargés d'exploiter les applications existantes au sein d'une même équipe.

Ce que l'on pourrait résumer en travailler ensemble pour produire de la valeur pour l'entreprise.

Certains utilisent la graphie DevOps.

Origine du nom[modifier | modifier le code]

Devops est la concaténation des trois premières lettres du mot anglais development (développement) et de l'abréviation usuelle ops du mot anglais operations (exploitation), deux fonctions de la gestion des systèmes informatiques qui ont souvent des objectifs contradictoires. Le mot a été inventé par Patrick Debois[1] durant l'organisation des premiers devopsdays à Gand en Belgique, en octobre 2009.

Apparition du concept Devops[modifier | modifier le code]

Pourquoi séparer Dev et Ops?[modifier | modifier le code]

Aux débuts de l'informatique d'entreprise, les applications étant de taille limitée et peu intégrées les unes avec les autres, la distinction entre Dev et Ops n'avait pas lieu d'être: la même équipe qui s'occupait de la maintenance du système se chargeait également d'y apporter les changements nécessaires pour le développement de nouvelles fonctionnalités.

Mais l'évolution de l'information d'entreprise a introduit de nouvelles contraintes qui ont conduit à un nouveau paradigme :

  • l'apparition de systèmes intégrés comme les ERP ou Progiciel de gestion intégré a augmenté la taille des applications et leur interdépendance ;
  • il est aussi apparu que l'état d'esprit Ops était assez différent de l'état d'esprit Dev, ce qui créait de facto une certaine polarisation des membres de l'équipe, soit plutôt Ops, soit plutôt Dev ;
  • l'inefficacité de mélanger tâches de type Ops et tâches de type Dev ainsi que le coût (en termes de temps de travail) du passage continuel d'un type à l'autre.

Pour ces raisons, il est alors apparu plus efficace de séparer les aspects Dev et Ops en plaçant les responsabilités respectives dans des équipes séparées. On parle alors souvent de "Build" pour la conception, de "Run" pour la maintenance et de "Change" pour l'évolution, généralement délivrée en mode projet (cf. Gestion de projet). Dans ce nouveau paradigme, les équipes sont organisées autour des mêmes systèmes et sont donc amenées à travailler main dans la main.

Apparition du conflit d'intérêt[modifier | modifier le code]

Dans la réalité, cette séparation des devoirs entre les deux types d'équipes a rapidement mené à un conflit perpétuel du fait de l'incompatibilité des objectifs respectifs. Ceci peut être illustré en considérant les 3 contraintes de la gestion de projet: coût, qualité/cadre de fonctionnalités et temps.

En effet, l'objectif principal d'une équipe Ops est de garantir la stabilité du système. De ce fait, l'équipe se focalise sur la contrainte qualité, au détriment du temps et du coût. La meilleure manière d'atteindre son objectif est de contrôler sévèrement la qualité des changements qui sont apportés au système qu'elle maintient.

De son côté, l'équipe Dev a pour objectif principal d'apporter les changements nécessaires au moindre coût et le plus vite possible, souvent au détriment de la qualité lorsque des retards viennent mettre le plan en péril.

L'antagonisme de ces objectifs, intrinsèques à l'activité de chaque type d'équipe, est encore exacerbé par la séparation des devoirs, au point que de conduire à un rejet de sa propre responsabilité et au blâme de l'équipe "sœur", l'équipe de développement blâmant son alter ego Ops pour les retards, et l'équipe de maintenance tenant l'équipe de développement responsable des problèmes de qualité du code et des incidents survenus en production de ce fait.

Plus généralement, organiser une entreprise comme un ensemble d'équipes que l'on va objectiver indépendamment les unes des autres avec des indicateurs spécifiques à chaque équipe, va générer des optimums locaux et des guerres entre équipes. Ce qui globalement pour l'entreprise n'est pas la meilleure chose. Un changement de paradigme est donc à nouveau nécessaire.

Lien avec l'agilité[modifier | modifier le code]

Le mouvement devops est né d'une part de la volonté de globaliser les méthodes agile à l'ensemble de l'entreprise et d'appliquer les principes de l'agilité à la production. Il est cependant possible d'être agile dans une équipe uniquement de développement, comme il est possible de mettre en place certains principes devops dans un environnement de développement "cascade".

devopsdays[modifier | modifier le code]

Les devopsdays sont des journées de conférences et de forum ouvert dont le thème est devops. Elles ont lieu dans le monde entier depuis 2009.

Aujourd'hui[modifier | modifier le code]

Aslak Hellesøy, auteur du logiciel Cucumber et coauteur de RSpec, dans son discours d'ouverture à l'Agile Grenoble, le 17 novembre 2010, a présenté devops comme une des quatre nouvelles tendances de l'agilité.

Adoption[modifier | modifier le code]

De nombreuses sociétés dans le monde adoptent les principes devops, entre autres Nokia, Google, American Express, Linkedin[2] et Amazon[3].

Comment atteindre cette fluidité entre Développement et Exploitation[modifier | modifier le code]

Sanjeev Sharma et Bernie Coyne [4] recommandent :

  • un déploiement régulier des applications, la seule répétition contribuant à fiabiliser le processus ;
  • un décalage des tests "vers la gauche" , autrement dit de tester au plus tôt ;
  • une pratique des tests dans un environnement similaire à celui de production ;
  • une intégration continue incluant des "tests continus" ;
  • une boucle d'amélioration courte (i.e. un feed-back rapide des utilisateurs) ;
  • une surveillance étroite de l'exploitation et de la qualité de production factualisée par des métriques et indicateurs "clé".

Notes et références[modifier | modifier le code]

  1. (en) Patrick Debois, « devops Cafe Episode 12 », devops Cafe (consulté le 31 mars 2011)
  2. (en) « Autometrics: Self-service metrics collection », sur engineering.linkedin.com, Linkedin
  3. (en) « Velocity Culture by Amazon.com » [PDF], sur assets.en.oreilly.com, Oreilly
  4. DevOps for Dummies, Sanjeev Sharma and Bernie Coyne

Liens externes[modifier | modifier le code]