Le facteur humain est, à mon sens, le plus important dans une démarche DevOps. Dans les deux articles précédents, je décrivais « bonheur de produire de la qualité ensemble », et je vulgarisais rapidement les concepts de Continuous Integration et Continuous Delivery apportant respectivement le bien-être du développeur et le confort de l’exploitant. Concentrons-nous ici sur le « produire ensemble », sur la charnière entre ces deux mondes, autrement dit sur la collaboration de ces deux ensembles d’équipes.

Le terme d’ensemble est choisi pour sa confusion entre l’adverbe et le nom, subtilité de la langue française dont j’abuse. La notion d’ensemble des équipes est important et mérite une présentation. Ce qui nous aménera à se poser la question de leur collaboration ensemble.

Un ensemble d’équipes de développement

Le développement au sein d’une entreprise, d’une association, d’un parti et autre activité, peut être assuré par plusieurs équipes de développeurs. De la kyrielle de cas, je n’en citerai que quelques-uns : le développement de plusieurs applications, voire plusieurs domaines d’applications, le développement d’une application modulaire, pour ne pas dire tentaculaire, le développement sur plusieurs sites, en suivant-le-soleil (follow-the-sun pour les anglophones), les développement d’amélioration d’une part et de maintenance d’autre part, voire avec une équipe d’urgence.

Bref, beaucoup de situations où il faut considérer l’équipe de développement au pluriel. C’est un premier constat.

Pas de bijection

Le second constat à effectuer est qu’il n’y a pas forcément de bijection entre une équipe de développement et une équipe d’exploitation. Une équipe d’exploitation peut gérer plusieurs applications qui relèvent de plusieurs équipes différentes de développement. Cas trivial. L’inverse est vrai aussi, par exemple une équipe de développement chargée d’une application de gestion de stock peut fournir les sites d’un groupe multi-national avec autant d’équipes locales (par pays) d’exploitation.

Un ensemble d’équipes d’exploitation

En abordant l’absence de bijection, j’ai pris un raccourci quant aux équipes d’exploitation. En effet, l’environnement de production est sous la bonne garde de plusieurs équipes. D’abord on trouve souvent les mêmes termes aux missions diverses, de la direction des opérations, de l’équipe d’exploitation, ou du centre de pilotage. Peu importe comment tout cela se décline, dans cette ensemble d’équipes il faut ensuite y ajouter, là aussi les appelations peuvent différées, l’équipe en charge de la sécurité, celle pour le réseau, celle configurant les firewall, celle chargée de l’infrastructure, celle du stockage, l’équipe dite virtualisation, les administrateurs systèmes (autant d’équipes que de système d’exploitation) les administrateurs des bases de données (autant d’équipes que de système de gestion), l’équipe du middleware (intergiciel pour les francophones), les équipes transverses concevant l’ordonnancement et/ou la surveillance. En bref, moult équipes bigarrées entrent dans la danse.

Sans être aguerri à tous ces termes, on perçoit aisément que les domaines de compétences sont très variés (troisième constat). L’usage du substantif « ensemble » est -je l’espère- une évidence.

La charnière…

Le dernier point qui n’a pas été explicité précédemment est qu’aucune équipe ne fait partie des deux ensembles. Nous pouvons donc confirmer que ce sont bien deux ensembles d’équipes qui se doivent de collaborer. Et le DevOps de rapprocher.

Bon an mal an, le point de concours entre ces deux ensembles d’équipes, est dans ce que livre une équipe de développement à l’entrée du cycle de déploiement, c’est-à-dire un package, fichier compressé contenant tous les objets, avec des documents d’instructions et/ou de paramétrages. Cette large caricature est assez fréquente somme toute. C’est avec ça, que tout commence. Non pas l’automatisation, au risque de décevoir certains lecteurs, mais bien le rapprochement entre les équipes.

Pour savoir comment plus tard on automatisera, il faut d’abord savoir ce que l’on veut déployer. Quels déploiements d’objets, de configuration, de paramètres ? Quelles dépendances, cohérences faut-il vérifier ? Quelles exigences et contraintes sont relevées par les équipes ? Quelle infrastructure faut-il réserver, mettre en place, configurer ?

Est-ce que tout ceci est déjà rédigé dans ces fameux documents livrés ? Parce qu’il le faudrait ! Cet inventaire est non seulement indispensable, mais doit toujours évoluer au fur et à mesure de la maturité de l’automatisation à venir (même si l’inventaire fera de plus en plus partie de l’automatisation elle-même). Avant d’être automatisé, tout ce qui constitue la livraison doit être connu. Et si c’est bien les équipes de développement qui formalisent tout le toutim, une grosse partie n’est pas de leur ressort, mais de celui des exploitants. Qui est mieux placé que les équipes d’un domaine pour vérifier et valider les choix faits (ou pas) dans ce domaine ? Par exemple, la gestion de l’espace disque est le domaine de l’équipe de stockage et non des administrateurs de base de données ou des développeurs, c’est ainsi, et c’est donc à l’équipe de stockage de vérifier, valider voire imposer leur politique clairement exposée tout en prenant en compte les desiderata de chacun.

Et à l’inverse, si une équipe souhaite une évolution d’une configuration, elle doit en référer aux développeurs pour qu’ils le prennent en compte et qu’ils l’intégrent dans leurs tests et dans les éléments à livrer. Par exemple, une mise en place de filtrage des ports doit être remontée bien avant l’incident en cours de recette (« ah mince il fallait prévoir un port, il faut qu’on redéveloppe tout le module ») !

Que les équipes exploitantes remontent des informations pour qu’elles figurent dans les tests et les livraisons futures est une chose, mais à quelle équipe de développement ? Et bien à l’ensemble des équipes de développement ! Ainsi de facto, l’uniformisation prend corps.

Cette collaboration est principalement une dynamique de circulation d’informations.

…pour sortir de l’ornière

C’est joli tout ça, mais concrétement ? Pragmatiquement, cela s’accompagne d’ateliers au cours desquels chaque équipe exprime ses besoins, et ses contraintes.

Ca serait bien que vous livriez un fichier de configuration contenant ça, ça et ça.
Après chaque livraison, on doit changer les droits sur ce répertoire, pourriez-vous les changer ? Comment pourrions-nous insérer une mise à jour des droits ?
Il est vraiment utile ce truc ?
A la fin de la livraison les logs sont supprimées, est-ce qu’on ne pourrait pas les garder un temps pour consultation ultérieure ?
Arrêtez de paramétrer ce timeout à 20ms, la norme est à 10ms ! Quelle norme ?
Quel espace disque vous conviendrez ?
Avec IE 6 !? ça me parait compliqué…
Comment peut-on le déterminer ? Installons un outil de mesure.

Au travers de ces exemples, vous comprendrez la nature des échanges. Parce que c’est aussi simple que ça ! Cette collaboration consiste avant tout à casser les clivages entre les différentes équipes et instaurer un dialogue continu. Ce doit être un échange permanent entre les équipes concernées. Et non, comme on le voit trop souvent, en période dite de crise. Il est bien plus aisé de définir des avancées en période posée. Mais si quelque chose ne convient pas, on en parle de suite, pas besoin d’attendre l’incident, pas besoin de talking pillow.

L’idée centrale est que le but de cette collaboration est de bonifier le package dans les optiques de chacune des équipes. L’automatisation se chargera ensuite du déploiement de cet élément clef.

Le package : Hier point d’achoppement, aujourd’hui point de concours, demain point commun.

Rappel des épisodes précédents :
DevOps introduction au rapprochement
Le cycle de vie, le Continuous integration et le Continuous delivery