Cet article fait partie de notre guide: DevOps ou la nouvelle Agilité

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

Le thème du DevOps revient régulièrement dans les discours des fournisseurs, des éditeurs et des équipes DSI. Pour autant, malgré l’engouement et les chiffres prometteurs, le périmètre et ce à quoi il répond semble encore bien flou.

En 2015, 12% des entreprises françaises ont adopté la démarche DevOps, contre 24% au niveau mondial (étude CA/Vanson/Bourne). Et 25% des 2000 plus grandes entreprises s’orientent vers le DevOps (Gartner). Mais, malgré l’engouement et les chiffres prometteurs, le périmètre et ce à quoi il répond semble encore bien flou.

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é :

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).

Pour aller plus loin

Au-delà du DevOps : DevOps ne suffit plus ? Essayez NoOps

Dernière mise à jour de cet article : février 2016

Participer à la conversation

2 commentaires

M'envoyer une notification dès qu'un autre membre commente.

En soumettant ces informations à LeMagIT.fr, vous acceptez de recevoir des emails de TechTarget et ses partenaires. Si vous résidez hors des Etats-Unis, vous consentez à ce que vos données personnelles soient transférées et traitées aux Etats-Unis. Politique de confidentialité

Merci de créer un identifiant pour pouvoir poster votre commentaire.

Merci pour cet article. Pour la gestion des tests fonctionnels, j'ajouterais l'incontournable SoapUi (Smartbear) qui a l'avantage de tester n'importe quel outil orienté SOA via ses web services et n'est donc pas lié à un langage en particulier (comme le PHP pour Behat)
Annuler
Article intéressant. Cependant je pense que DevOps doit avoir une ambition plus large et ne pas être limité seulement à une amélioration du Time to Market (TTM). Avec la culture DevOps et les changements organisationnels induits, on agit sur le triptyque : « Réduction du TTM », « Amélioration de la Qualité » et « Réduction des coûts de développement d’une nouvelle version ». C’est d’ailleurs la raison pour laquelle nous avons conçu un programme de 4 matinées pour la #DevOpsConnection reprenant les angles : Culture & Organisation, TTM, Qualité et Coûts.
Par ailleurs, même si on reste dans le cadre du TTM, on ne peut parler de Continuous Delivery sans parler des points de contention à lever, dans l’usine de développement, afin de gagner en vitesse (plus précisément les contraintes de dépendances liées aux tests et à leur automatisation).
Enfin, j’ajouterai comme point essentiel, la gestion des releases sans laquelle on ne peut assurer la cohérence du SI.
Annuler

- ANNONCES GOOGLE

Close