Répondant à l’antagonisme de deux mondes que sont le développement (le build) et les opérations (le run), l’un exigeant des évolutions constantes en réponse aux besoins du client final, l’autre aspirant à un maximum de stabilité pour tenir les engagements de services de ce même client. Un état de fait qu’il fallait résoudre et c’est DevOps qui se propose d’y répondre.
DevOps est mis en avant début 2010. Issue de la rencontre de deux tendances majeures. La première correspondant à un model dit “Agile Sys Admin” créé à partir du modèle Agile et des process Lean appliqué aux opérations. La seconde est une approche de travail collaboratif entre les services de développement et les équipes d’administrateurs et ce, à tous les stades du cycle de vie d’un projet : de sa création, à son déploiement et son support.
DevOps est donc avant tout un modèle de travail des plus pragmatique qui se caractérise par l’utilisation et la convergence d’outils communs entre les opérationnels et développeurs et une collaboration plus étroite voir une intégration des équipes. En induisant la collaboration et un esprit de corps lors d’un projet les points de contentions organisationnelles sont lissés et les intervenants impliqués et responsabilisés sur l’ensemble du processus.
DevOps introduit donc plusieurs aspects : méthodologique, opérationnel et technique
Méthodologique :
Une approche Agile transverse et synergique des deux pôles.
Opérationnel :
Une implication et une responsabilisation des équipes.
Technique :
La convergence mise en commun d’outils :
Le décor est maintenant planté, nous avons une définition de DevOps avec, ses caractéristiques, sa méthodologie, sa logique organisationnelle et un aperçu de son contexte technique.
Mais comment pouvons-nous donner vie à DevOps au sein de nos organisations ?
Si vous prêtez attention aux conversations actuelles autour de DevOps, il semble y avoir deux domaines majeurs sur lesquels il faut faire un focus :
Changer de Culture
Il faut changer de culture et réduire (voir supprimer) les frontières qu’il existe au sein des organisations. Pour cela il faut mettre en place des moyens d’incitations et de mesures à ce changement. Changer la culture d’une organisation ou ses métriques de performance ne sont jamais faciles. Toutefois, si vous ne menez pas correctement ces transformations, la promesse de DevOps sera difficile, voire impossible à atteindre.
Lorsque vous cherchez à influencer et donc à transformer les modèles organisationnels de l’entreprise, vous devrez être très attentif à la façon dont vous mesurez et jugez les performances. Ce que vous mesurez influence et oriente les comportements. Le succès des individus et des groupes doit donc être évalué dans le contexte de la réussite globale : du développement à la mise en opération.
Les méthodologies de suivies spécifiques peuvent toutefois être appliquées pour les segments de ce processus (tels que Agile d’un côté et Visible Ops de l’autre), tant que ces suivis peuvent être rapprochés pour en obtenir une vision unifiée.
Un Outillage unifiée
L’outillage est sans conteste la partie ou la communauté DevOps est la plus active. Cela n’a rien d’étonnant puisque c’est probablement le reflex de tout expert, ingénieur ou architecte que de chercher des solutions technique à des problèmes organisationnels. Cette même communauté met donc fortement l’accent sur les dernières avancées et outils « unifiant ». Si vous suivez ces discussions vous avez sans doute constaté la multiplication des références associées à un concept sur lequel la majorité des acteurs du marché se concentrent, à savoir : « Infrastructure as code ». Ainsi adresser les infrastructures comme code est un élément clé de DevOps, et il profitera à la fois aux Développeurs qui seront plus impliqués dans la spécification des configurations, et aux Opérationnels qui se verront inclure très en amont dans le processus de développement. Cette approche est structurante puisqu’elle induit de facto un processus end-to-end, imposant à tous de comprendre et de partager entre Dev et Ops.
Arn. F.
