DevOps

DevOps est un mouvement cherchant à rassembler les équipes intervenant dans le système d’information, réunissant en une même équipe les Dev en charge des évolutions et les Ops en charge de l’exploitation. L’objectif est ainsi de favoriser le travailler ensemble entre les équipes de développement et les équipes de production, produisant ainsi plus de valeur pour l’entreprise.

Au départ, les Dev et les Ops doivent atteindre des objectifs  conflictuels :

  • les Dev doivent apporter des changements au moindre coût et le plus vite possible, parfois au détriment de la qualité ;
  • les Ops doivent garantir la stabilité du système, ils se focalisent sur la qualité au détriment du temps et du coût; de plus il peuvent contrôler les changements et invalider une livraison si la qualité leur paraît insuffisante.

Il n’est donc pas rare qu’une équipe rejette la faute sur l’autre en cas de problème : les Dev en cas de retard (« les Ops nous ont empêché de livrer »), les Ops en cas d’incident de production (« les Dev nous livrent du logiciel de mauvaise qualité »). Cette guerre entre équipes est contre-productive et il devient nécessaire de rapprocher les deux équipes.

DevOps et agilité

Dans une certaine mesure, DevOps se situe dans le prolongement de l’agile. Pour rappel, l’agilité favorise les cycles courts, le feedback régulier, la repriorisation des tâches, une implication des métiers dans le cycle de développement.

Avec DevOps, on va également davantage impliquer les équipes de production dans le cycle de développement. Cela passe par une meilleure compréhension par les développeurs des préoccupations et contraintes de la production et inversement (de la même façon qu’en agile, les métiers et les développeurs cherchent à se comprendre davantage).

Avec DevOps, on assiste en quelque sorte à l’aboutissement du processus agile, puisqu’on ne se contente plus seulement de livrer le code sur des cycles courts, mais également de le livrer sous forme de logiciel exploitable sur des cycles aussi courts. Le DevOps a donc toute sa place et est même essentiel à un processus de déploiement continu.

DevOps en pratique

Mise en oeuvre des environnements

La mise à disposition d’environnements, que ce soit pour le test, la recette, la pré-production ou la production est généralement un point de friction : dans certaines entreprises cela peut prendre plusieurs mois (à la fois pour obtenir les ressources matérielles et logicielles, et pour installer l’environnement). A cela s’ajoute une connaissance parcellaire des contraintes de production de la part des Dev, l’expression du besoin pour l’environnement est émaillé d’incertitude et d’imprécisions. L’évaluation des besoins matériels et logiciels est souvent compliquée, les Ops attendant que les Dev fournissent une spécification précise (architecture processeur, nombre de coeurs, version des langages, de l’OS et des outils, etc.), les Dev attendant au contraire d’être conseillés par les Ops sur le sujet. La principale conséquence est d’avancer par essai et erreur jusqu’à obtenir un environnement correct, ce qui est une vaste perte de temps (et bien évidemment ajoute son lot de tensions supplémentaire).

L’amélioration de cet axe passe par l’utilisation d’outils de virtualisation, permettant d’instancier en quelques minutes des machines virtuelles avec environnement préinstallé couvrant les besoins des développeurs. Dans l’idéal, l’obtention d’une machine virtuelle se fait en quelques clics, à la demande, de façon reproductible et fiable. Il devient alors facile de remonter un environnement en partant de zéro. Les Dev gagnent également en autonomie en acquérant la capacité de monter eux-mêmes leur propres environnements.

Déploiement continu

Dans de nombreuses organisations, la mise en production de logiciel est encore vécue comme un événement douloureux et traumatisant, notamment à cause des facteurs suivants :

  • les responsabilités entre Dev et Ops sont cloisonnées, ceci aboutit inévitablement à des crispations et l’un devient rapidement bouc-émissaire de l’autre;
  • généralement la mise en production ne se passe pas comme prévu et nécessite de nombreux allers-retours entre les équipes et des phases de stabilisation qui prennent du temps et aboutissent progressivement à un sentiment d’échec;
  • il n’est pas rare de devoir gérer des situations de crises pendant les jours suivant la mise en production avec une très forte mobilisation des équipes.

En plus d’être fortement désagréable, la mise en production est également coûteuse, c’est pourquoi elle a tendance a être peu fréquente. Seulement, le fait de livrer peu souvent entraîne que :

  • à chaque livraison, on livre beaucoup de fonctionnalités ce qui rend la mise en production complexe ;
  • on n’est pas suffisamment rôdé et entraîné, la correction des problèmes prend donc plus de temps.

Voici quelques pistes pour réduire les difficultés et le coût de mise en production :

  • automatiser la mise en place des environnements prêts à l’emploi pour accueillir la livraison ;
  • automatiser la construction de logiciel (le « build »), la mise en oeuvre d’une usine logicielle prend tout son sens; le livrable construit doit être prêt à être déployé, en incluant éventuellement les scripts nécessaires au déploiement ;
  • livrer peu de contenu mais beaucoup plus souvent ;
  • mettre en oeuvre des patterns de déploiement.

Culture d’équipe

La culture d’équipe DevOps implique une responsabilisation commune de ce qui autrefois faisait les Dev et les Ops et de réduire ainsi le cloisonnement. Voici quelques pratiques utiles :

  • plus d’autonomie : les Dev devraient avoir accès en lecture à certains éléments de la prod, par exemple l’accès aux logs, aux métriques ou aux outils de supervision, sans nécessité une demande aux Ops à chaque fois ;
  • plus de porosité : les Dev devraient savoir comment fonctionne la prod et ce qu’il s’y passe, les Ops devraient avoir certaines connaissances sur le contenu, le rôle et le fonctionnement des applications ; on peut même envisager des intervenants à double casquette, à la fois Dev et Ops ;
  • plus de responsabilisation : les développeurs doivent avoir présent à l’esprit l’aspect livraison lorsqu’ils codent (principe « you build it, you run it ») en fournissant les scripts de déploiement.

 

Laisser un commentaire