Méthodologie DevOps ou comment éviter le syndrome du « C’est pas moi »

Alors que les processus agiles sont entrés dans les projets informatiques ces dernières années, une autre notion a vu le jour récemment : celle du DevOps. Aboutissement des méthodes agiles appliquées sur l’ensemble du processus informatique, le DevOps s’impose progressivement dans les processus de développement continu et de déploiement continu des applications.

Eh bien, là où les méthodes agiles interviennent au niveau de la relation client-fournisseur, le DevOps s’inscrit dans la relation entre les Dev engineers (Dev – développeurs) et les Ops engineers (Ops – exploitants systèmes en bon français). Ayant permis de faire tomber les barrières de conflits entre client et fournisseur, les méthodes agiles ont amené progressivement à l’avènement du DevOps pour fluidifier la relation entre les développeurs et les exploitants systèmes. L’ambition donnée au DevOps est de faire travailler en harmonie les développeurs et les exploitants systèmes afin que tous se comprennent et que chacun tienne compte des enjeux du travail de l’autre. En d’autres termes, le DevOps doit encourager la coopération et la collaboration des équipes de développement, de test et de production : pour aboutir à un pipeline optimisé.

Les applications multi-technologies, aux back-offices orientés services et aux fronts multi-devices sont autant de contraintes qui ont rendu les chaînes de développement plus complexes, plus coûteuses, sources de plus d’erreurs… Les questions que l’on se pose sont alors : comment uniformiser mon déploiement ? Quelle gestion de configuration des applications ? Comment uniformiser la supervision et la gestion de logs autour de la gestion d’applications ? Afin de répondre à ces questions, il faut tendre vers un processus de déploiement des applications qui soit le même quelle que soit la technologie de développement. Comment alors homogénéiser la solution délivrée et industrialiser le développement des versions ? Les applications ayant des cycles d’évolution de plus en plus courts, le DevOps devient essentiel afin de répondre à l’évolution rapide des besoins.

Assurant plus de souplesse pour le développement des différents composants et grâce à un outillage associé et des processus unifiés, la démarche DevOps permet de répondre à cette question.

Aujourd’hui, Hardis Group a fait évoluer sa plateforme de développement Adelia Studio afin qu’elle s’insère dans une démarche DevOps comme tout autre outil de développement.

Adelia est une plateforme de développement qui s’inscrit dans la chaîne de développement continu mais aussi dans le pipeline optimisé de déploiement continu.

L’intégration continue est désormais native dans Adelia Studio et piloté par des automates du type Jenkins/Bamboo/Graddle pour toutes les plateformes supportées par Adelia (Windows, Java mais aussi iSeries).

Les principes du DevOps encouragent la production d’événements par les développeurs qui permettent d’avoir une vision technico-fonctionnelle de l’application (par exemple, mesurer le débit fonctionnel de l’application). Avec une vision partagée des enjeux du run dès le développement, la plateforme Adelia Studio offre l’outillage permettant la production d’événements métiers pouvant être collectés en temps réel grâce au plugin pour les stacks ELK/Grafana. De ce fait, au travers de cet outillage type ELK/Grafana, la visualisation partagée et consolidée de tous les composants logiciels, fonctionnels et infrastructures permettent une identification plus rapide des dysfonctionnements et réduisent le temps de résolution.

Installer une démarche DevOps dans un processus opérationnel nécessite bien sûr des changements importants. Les principaux impacts sont perceptibles à trois niveaux :

• Impact Conception : dès le départ, le dev doit prendre en compte les besoins futurs du run. Il est nécessaire de penser les événements de la vie de l’application et les métriques utiles, par exemple les alertes, les débits…
• Impact Build (pour Adelia ici) : la compilation n’est plus pilotée par Adelia. C’est un automate (Jenkins/Graddle/Bamboo) qui compile et produit des artefacts (modules versionnés avec description de ses dépendances) et nécessite une conception modulaire des applications.
• Impact Déploiement :
  • Quel que soientt les composants et les technologies d’application multi-systèmes, le déploiement continu vise à automatiser le processus de déploiement de gestion de configuration dans la chaîne dev-recette-préprod-prod. Il convient alors de choisir et mettre en euvre les outils d’automatisation de déploiement type Chef/Puppet/Ansible…
  • Le déploiement continu nécessite également la prise en compte de la non-régression avec l’usage plus poussé de tests automatisés, de la sécurité, de la gestion de configuration…

La mise en place d’une démarche DevOps induit nécessairement des changements dans les méthodes de travail des DevOps.

Ces changements nécessitent une vision commune des objectifs, une démarche et un outillage partagé et peuvent entrainer une remise en cause des us et coutumes de chacun. Nonobstant, la crainte légitime liée au changement des méthodes de travail et des savoirs, il est du devoir de l’entreprise d’accompagner, de former et de transformer les équipes. Dans l’intérêt du projet, les équipes sont multidisciplinaires et ceci entraine le dé-silotage des organisations matricielles historiques.

Hardis Group vous accompagne de bout en bout dans la mise en place d’une démarche DevOps. Découvrez comment ici.