Last update: 22/03/2016 21:18

Agile DevOps

Aux débuts de l'informatique la spécialisation du travail entre ceux qui réalisaient les logiciels et ceux qui les mettaient en exploitation, qui en assuraient le support et la maintenance opérationnelle n

'existait pas : ceux qui perforaient les cartes et ceux qui en alimentaient les machines étaient les mêmes personnes ; ceux qui réalisaient les bandes magnétiques étaient aussi ceux qui les fixaient aux machines.

Lorsque l'informatique a été de plus en plus distribuée et que les programmes ne s'installaient plus sur 1 ordinateur, la séparation des métiers est apparue donnant ainsi naissance à cette division entre Dev et Ops : Dev pour désigner ceux qui créaient les programmes et Ops pour désigner ceux qui en assuraient le support et la maintenance opérationnelle.

C'est encore la situation de bien des entreprises aujourd'hui.

Cependant, avec l'émergence de nouveaux paradigmes dans l'univers de la distribution applicative cette ségrégation est de nouveau en train de disparaître.

Lorsque les Dev et Ops sont séparés, les Ops étant ceux qui doivent assurer le support sont aussi ceux qui sont les plus intéressés pour savoir ce qui s'est réellement passé dans une application lorsqu'une anomalie est signalée. C'est l'essor de la nécessité de logging et tracing (notamment).

Pour eux il devient essentiel de connaître tous les points de passage critiques dans une application et le contexte dans lequel l'application a opéré. Ce n'est déjà pas facile quand on traite le sujet pour une seule application installée sur une seule machine mais cela devient foutrement compliqué quand de multiples applications collaborent ensemble et qu'elles se trouvent sur des machines différentes, chacune disponible en de multiples instances. C'est la raison pour laquelle les Ops sont prompts à écrire scripts et programmes dont l'objectif principal, sinon le seul, est de réconcilier les traces, de les combiner, de les triturer. Ils sont ainsi équipés pour diriger les "enquêtes" en cas d'incidents, voire à produire les évidences nécessaires lors de tentatives de fraude. Les exemples sont innombrables.

Mais voilà la distribution applicative s'est complexifiée et depuis qu'on a célébré l'apparition de la virtualisation et du cloud computing les Ops ne savent plus où donner de la tête. Il semblerait qu'on veuille leur rendre la tâche impossible. Il leur est de plus en plus difficile de mener l'enquête. Leurs scripts et leurs applications de suivi opérationnel ont maintenant du mal à tirer la trame des événements.

C'est la raison essentielle pour laquelle on fusionne à nouveau les métiers : puisqu'il devient si difficile de suivre le cours des débats de l'extérieur on va le faite de l'intérieur et on va interagir directement avec ceux qui conçoivent les programmes pour leur insuffler la fibre Ops afin qu'ils soient sensibilisés aux besoins de suivi opérationnels directement dans les applications (ce qui ne va pas de soi sauf pour qui a déjà été confronté au client auquel il faut expliquer ce qui s'est passé !).

La tendance s'est encore exacerbée avec l'explosion des mobiles. Imaginez le casse-tête de suivi pour une application de mobile banking avec un utilisateur localisé en Italie accédant ses comptes détenus dans une banque belge alors qu'il se déplace en voiture tout en changeant d'opérateur tout au milieu de son utilisation avec des ruptures de connexion ! Allez donc lui expliquer si son virement a bel et bien été exécuté sachant que certaines parties de l'application sont complètement virtualisées. Voilà bien un exemple où une collaboration étroite entre Dev et Ops est souhaitée : l'applicatif se chargeant alors de fournir les évidences opérationnelles.

Voilà la naissance du terme DevOps, historique volontairement simplifié !

Actionnons à présent le terme "Agile" !

Dans une équipe "agile" on a déjà banni la spécialisation du travail : plus question de parler d'Analyste fonctionnel, d'Analyste technique, de programmeur, de testeur, de ... Chaque membre de l'équipe est tout cela à la fois. Cela évite bien des incompréhensions entre ces métiers : pas besoin de synchronisation et/ou mise au point si tout se passe dans le même cerveau. On diminue ainsi drastiquement le nombre d'interactions interpersonnelles et on fluidifie la communication. Par ailleurs on construit une application par petits incréments successifs que l'on démontre fréquemment et qu'on confronte ainsi régulièrement aux besoins. C'est l'histoire du tuteur et de l'arbre. On ne met pas un tuteur à l'arbre; on met un tuteur à une jeune plante dont on espère qu'elle deviendra un bel arbre. On la dirige ainsi tout au long de son développement.

Ainsi, en agile, on indique déjà sa préférence pour que les membres de l'équipe aient plusieurs casquettes. En leur ajoutant la notion de DevOps on augmente le nombre de casquettes : en plus d'être programmeur, analyste fonctionnel, analyste technique, testeur, un peu architecte et j'en passe le membre de l'équipe sera aussi opérateur.

Pour sûr cette grande concentration de compétences ne peut avoir lieu en une soirée par un étrange coup de baguette magique. C'est un véritable processus. L'entreprise qui ne comprendrait pas les raisons pour lesquelles Dev et Ops sont à marier aujourd'hui ou qui croirait que le seul nom suffit à garantir le bon aboutissement du processus est tout simplement appelée à disparaître à long terme. Qu'on se le dise.

Our website uses cookies to save your preferences. We kindly ask you to consent to our use of cookies when you first visit our website. If you do not consent, the sole recourse is to stop visiting our website. X