C’est maintenant indéniable, on réussit à faire du développement itératif et incrémental dans les grandes entreprises. Plusieurs fois, cependant, c’est lors du transfert à l’équipe d’opérations pour la mise en production que la sauce se gâche, du point de vue Agile du moins.
Dans les plus petites compagnies, l’équipe de développement prend souvent en charge la mise en production. Elle est à l’aise avec sont produit, connaît les dernières modifications et sait ce qu’il y a à faire. Les équipes plus disciplinées, lire professionnelles, automatisent le tout et utilisent des architectures qui facilitent les migrations et les retours en arrière.
Dans les plus grands déploiements, pour différentes raisons comme la sécurité et le volume, il y a généralement une équipe d’exploitation qui s’occupe des mises en production.
Un scénario typique pourrait ressembler à celui-ci. L’équipe de dev fournit une boite noire aux opérateurs, parfois peu de temps avant la date de mise en production. Tout le monde se ‘parle’ par courriel et boîte vocale. Et, finalement, lorsque le déploiement ne fonctionne pas bien et après un week-end sans dormir, le jeu du blâme commence. Pour la fois suivante, on exige un document de mise en production de 30 pages et une définition détaillée de toutes les configurations, des gels de code, des tickets préautorisés avec un délai de deux semaines… Deux équipes se forment. Eux et nous, et évidemment, ce sont eux qui ont tort et qui ne connaissent rien.
Le mouvement DevOps cherche à éliminer ce problème. DevOps, c’est un ensemble de principes et surtout une entente de collaboration entre l’équipe de dev et les opérateurs. Il s’agit de rendre Agile toute la chaine de développement jusqu’à la mise en production. Après tout, un produit non déployé a un ROI de zéro. Et on a tellement travaillé fort en dev pour maximiser le ROI qu’il ne faut pas s’arrêter là.
Avec DevOps, on implique les opérateurs plus tôt. On ajoute peut-être même quelques stories afin de les aider à faire leur boulot. On les écoute, car ce sont eux qui ont le contact direct avec notre application dans les conditions réelles d’utilisation. Du coup, cela a une influence sur notre architecture.
De l’autre côté, les opérateurs s’ajustent à notre calendrier d’itérations et ont une participation plus active aux activités de préproduction afin de commencer plus tôt à comprendre et automatiser le processus.
Au final, on utilise les mêmes outils pour la documentation et le débogage et on développe un langage commun.
DevOps, c’est évidemment beaucoup plus que ces quelques petites lignes. Faites une petite recherche sur le Net. Vous allez constater que c’est un mouvement en pleine émergence. Rien de révolutionnaire ni de vraiment nouveau, mais un ensemble de bonnes pratiques qui ont du gros bon sens.
Collaboration, écoute, langage commun, outils communs, processus légers, risques identifiés plus tôt, architecture adaptée… Ça ressemble drôlement à de l’Agile non?
L’idée de ce blogue m’est venue à la suite de la présentation intitulée « DevOps: Retour d’expérience chez eXo Platform » au GenevaJUG du mois d’août. Merci à Henri Gomez pour cette présentation.
