« DevOps, un changement culturel avant tout », par Sébastien DEON

DevOps = Dev + Ops

Le mouvement DevOps, contraction de Dev (Development) et Ops (Operations) se veut la réunion harmonieuse de deux fonctions du monde de l’IT aux objectifs bien différents : les développements d’une part et l’exploitation d’autre part.

Le seul objectif est ici de délivrer des services applicatifs aux clients dans le time-to-market, ce qui signifie qu’il s’agit de produits finis fonctionnels et en production avec tout ce que cela implique au préalable dans la chaîne de fabrication. Le DevOps permet de répondre à la question du «comment délivrer les services plus rapidement ? ».

Mais le paradigme de DevOps, antinomique par définition, peine pourtant à être institutionnaliser et à s’imposer au sein de l’entreprise.

Supprimer le « firewalling humain » pour automatiser la mise en production

L’idée de DevOps est de supprimer le mur qui sépare les équipes de développement des équipes de production afin de faire en sorte qu’une mise en production soit un non-événement et ainsi avoir une chaîne automatisée permettant de passer de la livraison continue (continous delivery) au déploiement continu (continuous deployment).

En supprimant les barrières culturelles et en mettant en place une véritable gouvernance, le code sera poussé en production en appuyant uniquement sur un bouton.

Dans ce contexte, le retour arrière n’est possible qu’en corrigeant le code initial et en l’injectant à nouveau dans la chaîne de fabrication. Certaines entreprises comme Amazon ou de grandes banques françaises ont déjà franchi le pas jusqu’à supprimer les accès administrateurs sur les plateformes de production pour faciliter cette nouvelle approche culturelle.

Agilité et DevOps font-il bon ménage ?

L’agilité est un terme utilisé dans de nombreux domaines (l’entreprise agile, le management agile, …) mais c’est dans le milieu des méthodes de développements du digital que ce terme tient son origine.

Dans une équipe de développement, il faut développer toujours plus vite et toujours mieux d’un point de vue qualité. Il faut pouvoir montrer au client le résultat d’une phase de développement régulièrement toutes les 2 à 3 semaines (on parle de sprints).

Le temps du développement avec la méthode séquentielle du cycle en V (analyse, spécification, conception, codage, tests, …) semble donc révolu. Les méthodes agiles (Scrum, Kanban, lean, …) sont désormais utilisées avec des outils qui présentent différents tableaux de bords comme par exemple les tableaux suivants :

• suivi de projet avec un backlog d’actions à effectuer
• management visuel (à l’aide de post-it)

Nous le voyons dans ce tableau, le travail de l’équipe semble s’arrêter quand le backlog est épuisé et que les développements, les tests et l’intégration sont effectués. Rien ne fait réellement le lien avec la production.

Dans une équipe classique d’exploitation, l’approche est ITIL et non agile. Il faut disposer des documents de mise en production, des dossiers d’architectures techniques, des scénarios de tests simplifiés et complexes afin de pouvoir rejouer un use case en cas de problème. En effet, en HNO (heures non ouvrées), comme les développeurs sont rarement soumis aux astreintes, l’équipe d’exploitation se doit être autonome.

Il est cependant tout à fait possible d’introduire de l’agilité dans ITIL en créant une équipe DevOps par projet aux allures de « pizza teams » et aux compétences diverses : des développeurs, des testeurs, des exploitants, des chefs de projets. C’est l’équipe toute entière qui est responsable et qui est chargée d’effectuer le déploiement continu.

Le DevOps, un sponsor, des acteurs et une organisation

Comme tout nouveau changement amène son lot d’incertitudes et d’angoisses au sein des équipes, il faut commencer par savoir où l’on veut aller et écrire une histoire en ce sens. Ensuite, il faut l’expliquer, identifier les facteurs clés de succès, les zones de risques, calculer les coûts de production et le retour sur investissement. Il faut également avoir un sponsor, par exemple, la Direction Générale ou une Direction Métier.

La suite est plus simple car les acteurs sont déjà en place au sein de l’organisation, mais avec des rôles et des positionnements différents de ceux requis par le DevOps : les équipes de développement sont déjà organisées, en place et outillées ; elles produisent du code, effectuent des tests unitaires, des tests métiers, des tests de performance, des tests de sécurité, des tests d’intégration. Et cela s’arrête là !

Pour la mise en production, il faut faire appel à l’équipe d’exploitation avec ses contraintes bien différentes. Là où le développeur pense coding, correction de bugs, factorisation, langage ; l’exploitant pense robustesse, fiabilité, sécurité. Ce dernier a besoin d’être rassuré car c’est lui qui doit assumer les problèmes potentiels (pic de charge, restauration d’une sauvegarde, plantage fonctionnel, attaques externes, lenteur de la base de données, etc.).

Enfin, la gouvernance permet de mettre en œuvre les différents processus (charte projet, acteurs, parties prenantes, risques, bénéfices, …, les méthodes, les outils et technologies). Il faut également faire appel au client et l’intégrer à l’équipe.

Par exemple, le code ne peut être poussé en production que s’il est validé par un processus de livraison.

Quels sont les outils ?

En 2016, le marché des outils permettant la mise en œuvre de DevOps est évalué à 2,3 milliards de dollars (Gartner).

Pour réussir un bon DevOps, il faut également des outils technologiques qui interviennent dans l’UDD (Usine De Développement) :

• Gestion du développement : la production du code s’effectue avec des outils propres aux développeurs
  • un IDE (environnement de développement intégré) comme Eclipse, PHPStorm, WebStorm, Visual Studio, Delphi, …)
  • un framework de développement (Symfony, Ruby on Rails, JavaFX, Apache Struts, …)
  • un outil de requêtage SQL (SQLDevelopper, Toad, …)
  • Gestion du stockage du code : le code doit être poussé sur dépôt central permettant la mutualisation entre les développeurs d’une même équipe. Des outils comme Git, GitLab, GitHub, Bitbucket, CVS, Subversion ou Mercurial peuvent ainsi être utilisés.
  • Gestion de l’intégration continue (CI): Le code doit générer automatiquement des builds à l’aide d’un gestionnaire d’intégration continue comme Jenkins (fork de Hudson), TeamCity, CruiseControl ou Tinderbox. Avec Jenkins, le plugin buildbreaker permet de stopper la création du build si les analyses Sonar de qualité de code ne sont pas bonnes, au regard des critères de mesures choisies
  • Gestion de la qualité de codes : de nombreux outils comme SonarQube ou Jacoco peuvent être utilisés. Ils permettent d’effectuer des analyses de codes au plus tôt dans le développement et servent à des fins d’amélioration continue.
  • Gestion des tests : les tests unitaires ont des outils de la famille xUnit comme Junit (monde Java) et PHPUnit (monde PHP), JSUnit, PyUnit, et Test :More pour effectuer des TUs. Les tests métiers disposent d’outils comme Selenium, Behat, Cucumber, RFT (IBM), QF Test (Quality First Software), SilkTest (MicroFocus), Unified Functionnal Testing (UFT). D’autres types de tests doivent être effectués comme les tests de sécurité (OWASP, etc.), les tests de performances (JavaMelody, outils d’APM, JMeter, etc.).
  • Gestion de projets et collaboration (Redmine, Atlassian, etc.)

D’autres outils complètent la panoplie et permettent d’augmenter l’automatisation et ainsi d’améliorer la productivité :

• Les plateformes IaaS (CloudForms, vRealize, AWS, Google App Engine, Mirosoft Azure, etc.) qui vont permettre de provisionner en automatiques les VMs nécessaires au fonctionnement de l’application
• Les plateformes PaaS (Openshift, BlueMix, Cloud Foundry, Azure, etc.)
• Les gestionnaires de configuration (Puppet et Chef, Ansible)
• Les gestionnaires de containerisation (Docker)

Pour conclure, DevOps est un changement de culture et de mentalités qui bouleverse les organisations établies. La démarche dispose cependant de tous les ingrédients pour réussir (acteurs, gouvernance, méthodes et outils) mais comme elle est plutôt jeune (moins de 8 ans), elle a besoin de temps pour devenir mature et s’imposer comme élément incontournable de productivité.

Si elle est partagée par les équipes sans jamais être imposée, elle deviendra le facteur de décloisonnement indispensable pour améliorer la qualité et les performances des applications, pour améliorer l’expérience utilisateur mais aussi la collaboration inter-équipe.

Sébastien Déon (@sebastien_deon sur Twitter) est directeur technique adjoint chez Pharmagest Interactive. Il est à la tête du service Architectures Techniques, Outils et Méthodes au sein de la Direction R&D de la société.  Il est également l’auteur de plusieurs ouvrages dédiés notamment aux technologies Open Source, comme OpenStack, dont nous nous faisions l’écho dans LeMagIT, à Zimbra (messagerie collaborative) ou encore à Asterisk (VoIP et ToIP pour entreprise).