Rapide rappel, DevOps est né il y a environ une dizaine d'années, et plus précisément en 2007, de la tête d'un certain Patrick Debois. Il dressa un constat affligeant concernant les relations entre dev et ops : il n'y en a pas et s'il y en a, elles ne sont pas bonnes.
En d'autres termes, il s'agit de deux mondes dont les préoccupations et les enjeux ne sont pas identiques. Et très égoïstement et/ou à cause d'un management ne le permettant que trop rarement, ces deux univers restent bien éloignés et c'est mieux ainsi.
De ce triste constat, l'idée a germé pour trouver des axes d'améliorations d'une communication qui dépasse le système de ticketing. Soyons honnête, ce magnifique outil dans lequel dev et ops communiquent des lettres d'amours passionnées n'est clairement pas une invitation à la fluidité. À l'époque, les outils étaient assez rares pour mettre en place des processus dits DevOps (déploiement continu, livraison continue, monitoring centralisé, ...). Aujourd'hui, il en existe de nombreux et surtout des plateformes massivement automatisables. Mais les outils et plateformes ne font pas tout et notre ami Patrick Debois, accompagné d'un certain nombre d’acolytes, déterminèrent que DevOps représentait aussi et surtout un enjeu pour l'état d'esprit (mindset). Vous trouverez d'ailleurs une idée de l'ambiance générale en lisant cet article.
Mais les outils et plateformes ne font pas tout et notre ami Patrick Debois, accompagné d'un certain nombre d’acolytes, déterminèrent que DevOps représentait aussi et surtout un enjeu pour l'état d'esprit (mindset).
Alors pourquoi ce titre un peu racoleur ? Tout simplement parce que le buzz est en train de s’essouffler au profit de quelque chose d’établi. Vous ne pouvez plus considérer aujourd'hui travailler sans vous posez la question : est-ce que toutes les méthodologies de travail sont bien en place de manière transverse sur l'ensemble de mon produit/projet ?
Prenons l'exemple de la conduite de projet agile. Est-ce que vous pensez raisonnablement pouvoir conduire aujourd'hui un projet en "waterfall" (bien que j'admette qu'une partie de Curiosity a dû être menée de cette manière) ? 99% des projets informatiques peuvent être menés via Scrum, Kanban, Lean et autres. Alors pourquoi n'en serait-il pas de même pour la partie la plus proche de la production ? Mettre en place les outils et la culture inhérente à DevOps dans le cycle de vie des projets n'est pas une option ou un phénomène de mode. Comme pour la conception de l'architecture applicative et d'infrastructure, vous vous devez de poursuivre la réflexion et notamment sur les liants entre toutes ces strates techniques et organisationnelles. Agilité en amont, DevOps en aval, un peu comme dans la préparation d'un menu : l'entrée, le plat de résistance, le dessert et le vin qui accompagne, se font idéalement en harmonie (bien que l'idée de boire un Romanée-Conti grand cru avec un Kebab doit être une expérience intéressante).
Comme pour la conception de l'architecture applicative et d'infrastructure, vous vous devez de poursuivre la réflexion et notamment sur les liants entre toutes ces strates techniques et organisationnelles.
DevOps, comme tout bon buzzword, comporte son lot de magie. Il n'est pas rare d'entendre lors de diverses réunions où les équipes sont constituées : "il nous faut un DevOps". L'air de rien, quand vous entendez ce type de remarque, je pense que l'on peut estimer qu'il s'agit d'une profonde incompréhension concernant la culture DevOps. Ma réponse à cette réplique est que tous les membres de l'équipe doivent avoir dans leur cerveau, en tâche de fond, un processus DevOps. Alors certes, vous aurez des profils plus DEV que OPS, ou le contraire, que l'on pourrait d'ailleurs écrire de cette façon : DEVops ou devOPS pour appuyer sur le domaine dans lequel se trouve l'expertise. Mais ne parlez pas d'un profil DevOps qui serait en fait une sorte de magicien qui possède toutes les solutions ; faites plutôt appel à un coach DevOps qui positionne votre équipe sur les bons rails. Cela doit se faire d'une part au niveau management, pour présenter tous les bienfaits, et d'autre part au niveau développeur / sysadmin pour ouvrir à la discussion. Nous envisagerons par exemple un premier atelier de sensibilisation. Il faudra ensuite repenser une partie de l'organisation actuelle pour la fluidifier. Ces deux derniers points sont des sujets qui ne peuvent se décrire dans ces quelques lignes et c’est pour cette raison que nous nous investissons chaque jour pour prêcher la bonne parole auprès de nos clients.
[Shameless plug : Vous souhaitez venir rejoindre l’aventure WeScale afin de prêcher la bonne parole auprès de nos clients, n’hésitez pas à nous faire signe. Nous sommes toujours ouverts pour discuter, partager et nous améliorer.]