15 Jan 2017

Quelques généralités sur DEVOPS

>>> Pourquoi un post sur DEVOPS ?

DevOps as a binary code with blurred background 3D illustration

  •  DEVOPS est un terme assez récent (2009) et très à la mode. Comme beaucoup d’autres Buzz-words, la signification exacte du terme est parfois déformée : DEVOPS est ainsi souvent compris comme étant une simple automatisation des déploiements applicatifs… ce qui est très réducteur. Le but de ce billet est donc de rappeler ce qu’est DEVOPS et ce que ça n’est pas. Ne vous attendez pas à trouver une quelconque information révolutionnaire, mais simplement quelques rappels pour mettre en évidence des idées fausses qui peuvent circuler çà et là. Selon de récentes statistiques, le temps moyen passé sur une page internet est en chute libre. Donc, si vous êtes du genre pressé, vous pouvez aller lire le paragraphe DEVOPS en une coquille de noix (DEVOPS in a nutshell) à la fin de ce billet, ça vous prendra moins de 30 secondes à lire et vous trouverez les informations principales de ce billet.

DEVOPS, c’est quoi ?

Venons-en au fait, voici une définition de DEVOPS :

DEVOPS : mouvement, démarche dont le but est de réaligner les processus et objectifs de l’IT sur les besoins métiers afin de maximiser la valeur métier produite par l’organisation.

Cette définition laisse entendre que tous les membres de l’IT n’ont pas toujours les mêmes objectifs et que ces objectifs n’ont pas forcément de lien avec ceux du métier. En fait, la réalité est pire : il est fréquent que les organisations fixent des objectifs antagonistes à différents départements de l’IT et demandent à ces départements de travailler ensemble. Cela entraine des incompréhensions, voire des conflits et ne favorise pas l’efficacité de l’organisation.

>>>> Origine du Terme <<<<

DEVOPS est la concaténation des termes Développement et Opérations… ou pourquoi pas de Développeurs et Opérationnels si on envisage les choses sous l’aspect humain.

Pourquoi avoir choisi ce nom ? Tout simplement parce que les DEV et les OPS sont les parfaits représentants des objectifs divergents de l’IT :

  • Les développeurs doivent produire rapidement et à moindre coût de nouvelles fonctionnalités. Chaque projet doit faire un délicat arbitrage entre Coût, Qualité, Délai et Scope. L’organisation a parfois tendance à fixer les impératifs en termes de coût, de délai et de scope, ne laissant que la qualité comme variable d’ajustement. La conséquence de cela est un arbitrage de la documentation ou des phases de tests (ou des deux) afin de tenir les autres contraintes. De plus, les développeurs ont souvent tendance à vouloir utiliser de nouvelles technologies pas forcément éprouvées dans le but de gagner du temps de développement.
  • les opérationnels eux ont pour mission de privilégier la stabilité, la qualité et la fiabilité de leurs systèmes. Ils sont responsables des pannes et ce sont eux qui doivent gérer les incidents. L’organisation peut ainsi leur demander de produire des powerpoint de justification pour chaque dysfonctionnement et peut même impacter leur rémunération variable si les dysfonctionnements sont trop nombreux. En faisant cela, l’organisation rend les opérationnels frileux et hostiles à tout changement. Les opérationnels ont donc une tendance à privilégier la qualité, au détriment de la rapidité.

Ces objectifs différents font que les DEV et les OPS ont des opinions souvent négatives les uns des autres :

    • Pour les développeurs, les opérationnels sont des gens qui les ralentissent, qui visent à l’immobilisme et qui privilégient la stabilité des environnements de production par rapport à la mise en place de nouveaux environnements de développement et de test.
    • Pour les opérationnels, les développeurs sont des gens qui mettent des applications en production de manière inconsidérée et sans les avoir suffisamment documentées et testées, puis qui s’en désintéressent : leur laissant gérer les inévitables incidents.

Ces oppositions sont largement répandues et sont souvent perçues par le Métier qui a tendance à perdre confiance dans l’IT. En effet, comment faire confiance à des gens qui perdent du temps et de l’efficacité dans des guéguerres internes ? L’IT n’est pas perçue comme étant capable de parler d’une seule voix.

 

>>> Une Organisation schizophrène de l’IT calquée sur des notions comptables <<<<

L’organisation est responsable de cette opposition entre DEV et OPS. En fait, cette opposition est plus générale : c’est une opposition entre le mode projet et le mode Fonctionnement. Cela est dû à un découpage de l’IT pour répondre à des notions comptables : l’investissement et l’amortissement.

Pendant les phases de projet, phase d’investissement, les développeurs sont impliqués, mais pas seulement. Il y a les chefs de projets, des représentants métiers, la qualification, les tests, les architectes, etc. Tous les membres du projet sont missionnés pour mettre en place un maximum de fonctionnalités en un minimum de temps.

De l’autre côté, pendant les phases de fonctionnement (phase d’amortissement), de nombreuses personnes sont impliquées : le helpdesk, les fonctions support, les responsables qualité, le monitoring, les opérationnels, etc. Les phases de fonctionnement doivent permettre de rembourser les investissements faits, donc les outils informatiques doivent rester en ligne suffisamment longtemps pour cela. Et il faut éviter les pannes pour rester dans les objectifs fixés

Bref, tout l’IT est impacté par cette organisation basée sur des notions comptables, pas seulement les développeurs et les opérationnels. Ce sont toutefois ces populations qui ont été retenues pour personnifier cette séparation des objectifs. Le mouvement pour corriger ceci s’appelle donc mouvement DEVOPS, mais aurait tout aussi bien pu s’appeler PROFON (Projet / Fonctionnement) ou PRORUN ( Project / Run).

 

>>> Concepts et principes DEVOPS <<<<

Certaines pratiques sont largement répandues dans la mise en place de DEVOPS. En voici quelques-unes parmi les plus importantes :

  • Intégration continue :

L’intégration continue est une technique de développement dans laquelle chaque développeur d’une équipe de développement intègre fréquemment son travail avec celui des autres membres de l’équipe. Cette technique n’est pas spécifique à DEVOPS, mais est néanmoins une pierre angulaire au bon fonctionnement de DEVOPS.

De manière générale, DEVOPS peut s’appuyer sur toutes les techniques de développements agile et lean.

  • Déploiement continu :

Le déploiement continu, ou automatisé, des applications est LA pratique qui est la plus connue de DEVOPS. C’est celle que tout le monde a en tête. En effet, cette technique qui consiste à provisionner les divers environnements applicatifs, puis à déployer automatiquement les applications sur ces environnements, à faire les modifications de données nécessaires, à tester les applications déployées de manière automatique. Et à prévoir des retours arrière automatiques en cas de dysfonctionnement.

Le déploiement continu peut se faire sur tous les environnements, y compris la production. Des workflows de validation peuvent être inclus à ces processus ainsi qu’une gestion des droits de déploiement. Les personnes demandant le déploiement en production n’étant pas forcément les mêmes que sur les autres environnements.

Bref, la mise en place du déploiement continu ne remet pas en cause d’autres grands principes de partage des rôles, de traçabilité, d’audit… bien au contraire.

  • Planification des versions et audit des fonctionnalités :

La planification des versions permet aux entreprises de prévoir à quelles dates elles peuvent déployer une fonctionnalité et la mettre à disposition de leurs clients. DEVOPS vise à faciliter et à fiabiliser cette planification en mettant en place des versions plus petites et livrées plus souvent. Ce qui permet une meilleure prédictibilité des versions.

De plus, la date de mise en place ainsi que les modifications apportées aux fonctionnalités sont tracées et donc auditables par la suite.

  • Feedback :

DEVOPS repose également sur la mise en place de mesure afin d’évaluer les processus ainsi que la qualité et la performance des applications. Ces retours sont donc potentiellement multiples : mesure de sondes, retour client ou utilisateurs via des tickets, etc. L’organisation doit donc mettre en place des processus de gestion de feedback.

Ces feedbacks et ces mesures continues permettent de détecter plus rapidement les incidents de PROD et de pouvoir les faire analyser par les personnes compétentes, DEV ou OPS, ou les deux. Un des points essentiels de DEVOPS est de permettre aux Développeurs d’avoir accès aux logs de PROD rapidement et facilement, afin d’avoir suffisamment d’information pour diagnostiquer les problèmes.

  • Amélioration continue :

Mesurer c’est bien. Mais utiliser ces mesures pour s’améliorer, c’est mieux.

L’adoption de DEVOPS n’est pas quelque chose qui peut être fait de manière ponctuelle. Une fois que l’adoption a été faite, il ne faut pas graver les pratiques dans le marbre, mais au contraire essayer de les améliorer de manière permanente. Que cette amélioration soit menée par des équipes dédiées ou au contraire faites par les équipes concernées n’est pas très important, ce sont deux options possibles.

  • Provisionnement automatique des environnements (Infrastructure as Code) :

Dans le cadre de DEVOPS, la mise en place automatique d’environnement est grandement encouragée. Cette pratique permet de s’assurer que tous les serveurs, et plus généralement les composants seront installés et configurés de la même manière sur tous les environnements. Cela peut se faire par exemple à l’aide de scripts qui seront archivés comme du code (de l’application) et pourra permettre notamment de gérer le versioning des infra. C’est le concept d’infra as code.

Le déploiement automatique des environnements permet d’éviter les erreurs de configuration et donc d’améliorer la qualité. Cela permet également aux opérationnels de gagner un temps considérable et de se concentrer sur d’autres tâches. Il faut noter que les fonctionnalités offertes par le Cloud facilitent grandement cette pratique.

  • Tests continus

Si les déploiements sont faits de manière automatiques et continue, il est important qu’il en soit de même pour les tests. Ces tests automatiques doivent couvrir le déploiement et la configuration des environnements, ainsi que les tests d’intégration, les tests fonctionnels sur des données significatives sans oublier ni la sécurité, ni la performance.

  • Test sur des environnements similaires à la production (« Shift Left ») :

Les pratiques de développement TDD (Test Driven Development) permettent aux développeurs d’écrire les tests avant de développer l’application. Cela permet de tester le code et de vérifier la non régression lors de chaque modification de code. Mais cela ne suffit pas à s’assurer de la qualité de l’application. Il faut pouvoir tester sur des environnements similaires à la production en termes d’infrastructure ou de données, le plus tôt possible dans le cycle de développement. En effet, plus un bug est découvert tôt, moins il coute cher à réparer.

 

>>> Avantages de la démarche DEVOPS <<<<

En réalignant les objectifs de toutes les parties prenantes sur les besoins métiers, la démarche DEVOPS permet d’obtenir un certain nombre de résultats. En voici quelques-uns, les plus importants :

  • Réduction des cycles de livraison : meilleur time-to-market. 

Entre le moment où une fonctionnalité est spécifiée et le moment où elle arrive effectivement en production, l’intervalle de temps doit être le plus court possible.

  • Amélioration de la qualité 

La responsabilité du bon fonctionnement d’une application est partagée entre les différentes équipes, donc tout le monde a intérêt à ce que les applications fonctionnent au mieux, sans incident. De plus, la mise à disponibilité d’environnements de test similaires à la production permet de tester plus en amont pendant les phases de conception, ce qui réduit considérablement les coûts de correction de bugs

  • Meilleur feedback métier :

La démarche DEVOPS comprend une partie de mesure et d’analyse de l’existant, afin de permettre des améliorations. Les boucles de feedback doivent être les plus courtes possibles. Le métier peut ainsi communiquer directement avec les personnes techniques afin d’expliquer au mieux les problématiques rencontrées

  • Optimisation des processus :

Note : l’optimisation des processus est différente de l’automatisation. L’optimisation vise à la suppression de tâches inutiles ou à la modification de tâches trop compliquées pour les simplifier.

Si les déploiements se font plus réguliers, les équipes ont intérêt à optimiser les processus afin d’en améliorer l’efficacité et d’en diminuer les risques d’échec. Les processus évoluent donc en permanence et doivent être continuellement améliorés et optimisés en gardant à l’esprit que tous les processus DEVOPS doivent être vus comme des processus métier permettant de délivrer plus de valeur et plus rapidement.

  • Automatisation des tâches à faible valeur ajoutée :

L’automatisation des tâches répétitives et à faible valeur ajoutée est une pratique recommandée et régulièrement mise en place dans le cadre de DEVOPS. Cela permet de gagner du temps et de la qualité. Les équipes techniques peuvent ainsi se concentrer sur les activités qui apportent de la valeur métier.

En alignant les objectifs et les responsabilités de tout le monde, il n’y a plus de « guerre » interne au niveau de l’IT : le Métier a un seul interlocuteur qui aura pour seul objectif de satisfaire ses besoins. La Valeur Métier est mise au centre de toutes les préoccupations de l’IT : Il sera donc plus facile d’impliquer le Métier à toutes les problématiques IT.

 

>>> La culture DEVOPS <<<<

La démarche DEVOPS nécessite de développer une culture bien particulière.

Tout d’abord, il faut faire accepter cette démarche DEVOPS à chacun des acteurs impliqués. Cela est possible si on démontre l’intérêt de la démarche à chacun : la démarche doit leur simplifier la vie.

  • Les développeurs peuvent trouver leur intérêt à la démarche DEVOPS, si on leur fournit rapidement des environnements de tests qui leur permettront de tester leur code dans des conditions similaires à la production. On peut également leur permettre d’innover en utilisant des technologies récentes et adaptées à leurs développements.
  • Gagner l’acceptation des opérationnels peut se faire en limitant les risques des mises à jour applicatives. Partager les stratégies de test et de recette avec eux est une bonne manière de le faire. Cela peut également se faire en envisageant des processus de retours arrière rapides et fiables. Le concept « d’Infrastructure as Code » permet d’envisager des déployer des infrastructures entières simplement en exécutant des scripts de configuration et non pas en installant manuellement chaque serveur.
  • Les testeurs ont également intérêt à avoir au plus tôt des environnements semblables à la production et à avoir accès à un maximum de logs. De plus, les tests doivent être automatisés au maximum afin d’être joués automatiquement lors de chaque déploiement. Les Tests de Non Régression ne sont alors plus un problème.
  • Les fonctions support et le helpdesk gagnent des interlocuteurs réactifs et avec le bon niveau d’information : ils n’ont pas besoin de chercher les logs. Les délais de traitement et le nombre d’incidents est réduit.
  • Fournir des applications mises à jour régulièrement pour répondre à des besoins Métiers, de manière fiable permet de gagner la confiance du Métier et à les impliquer dans le processus de mise à jour des applications.

Ensuite, il faut que l’organisation dans son ensemble soit prête à accepter l’échec. L’échec doit être vu comme un élément inévitable et il faut que chacun soit préparé à l’affronter. La culture DEVOPS n’incite pas à empêcher l’échec à tout prix. Il faut par contre être prêt à affronter un problème et à le corriger dans les plus brefs délais. Cela nécessite la coopération et l’implication de tous. L’échec ne doit donc pas être sanctionné, par contre, il doit être analysé et des leçons doivent être tirées. De plus, des mécanismes peuvent être mis en place pour traiter automatiquement un problème et le masquer aux yeux des utilisateurs.

De l’acceptation de l’échec nait donc une culture d’amélioration continue. C’est un point essentiel de la culture DEVOPS. Les pratiques mises en place doivent être mesurées, puis analysées afin d’aboutir à des propositions d’améliorations et à leur mise en place.

 

>>> Conclusion <<<<

DEVOPS n’est pas une méthode ou un framework de pratiques à appliquer de manière systématique. Selon les organisations, il y a différentes implémentations de DEVOPS. Ce qui fonctionne dans une entreprise peut lamentablement échouer dans une autre. Une bonne démarche DEVOPS doit tenir compte des différences culturelles de l’entreprise et faire en sorte que tous les intervenants adhèrent à la démarche.

DEVOPS en une coquille de noix ( DEVOPS in a Nutshell – ie. En moins de 30 secondes)

DEVOPS est une démarche qui consiste à remettre les objectifs du métier au centre des processus IT. Cette démarche nécessite l’implication et l’adhésion de tous, et pas seulement des DEVeloppeurs ou des OPérationnelS (qui ont pourtant donné leur nom à la démarche). Cette démarche doit être adaptée à chaque organisation et nécessite de développer une culture d’optimisation, de mesure et d’amélioration continue. L’automatisation des tâches à faible valeur ajoutée doit permettre des déploiements rapides, fiables et reproductibles. L’échec doit être accepté et anticipé pour être traité le plus rapidement possible.

  • Prochains articles concernant le sujet DEVOPS :

Idées Reçues

Impact de DEVOPS sur l’organisation et les équipes

Impact de DEVOPS  sur les Processus (ITIL inside)

Impact de DEVOPS sur l’Infrastructure

A suivre.

Share