16 Jan 2017

Idées reçues sur DEVOPS

DevOps concept sign on white background

  • DEVOPS est AGILE ! Oui ! C’est même tout l’intérêt de la démarche : amener de l’agilité jusqu’en Production.
  •  DEVOPS, c’est seulement pour les développeurs et les Opérationnels. Si vous avez bien lu le précédent billet (et j’espère que c’est le cas), vous devriez avoir compris que cela nécessite la contribution et l’adhésion de tous. Les développeurs et les opérationnels ne peuvent pas aller contre le reste de l’organisation : il faut que tout le monde aille dans le même sens.
  • DEVOPS, c’est seulement pour les pure players du Web (Google, Amazon, Netflix, etc) Et bien non ! Les processus et les méthodes que l’on peut mettre en place dans le cadre d’une démarche DEVOPS sont suffisamment matures et éprouvés pour être adoptés par toutes les sociétés, y compris les plus grandes. S’il y a plusieurs systèmes complexes et interdépendants, DEVOPS permet de coordonner les changements afin d’en limiter les impacts et de réduire les difficultés liées à cette complexité.

  • DEVOPS = No OPs : Non !

Le No Ops est un modèle d’implémentation de la démarche DEV OPS, mais ce n’est pas le seul. Le No Ops vise à dispatcher les tâches opérationnelles dans les autres équipes et à ne pas avoir de rôle purement Opérationnel. Cela peut être fait en utilisant les facilités offertes par le Cloud.

Le DEVOPS ne signifie pas la fin de la population des Opérationnels. Au contraire, les Opérationnels en étant impliqués plus tôt dans les projets peuvent devenir force de proposition et se concentrer sur des tâches plus valorisantes que les déploiements applicatifs ou la gestion d’incidents dont ils ne sont pas forcément responsables.

  • Dans le modèle DEVOPS, les Opérationnels doivent apprendre à développer : Pas vraiment.

Ils n’ont pas besoin d’apprendre de langages complexes. Par contre, s’ils écrivaient déjà des scripts, ils peuvent être encouragés à continuer à le faire et même à généraliser cette pratique. Les scripts permettent toutes les actions concernant l’infrastructure. Il est alors possible de gérer les versions de ces scripts pour gérer les versions d’infrastructure : c’est le concept « d’infrastructure as code ».

  • DEVOPS n’est pas compatible avec ITIL (Information Technology Infrastructure Library): Faux !

ITIL a mauvaise réputation car ses principes sont souvent déployés de manière intégrale sans penser à la plus-value produite. De plus ITIL est souvent déployé dans des contextes complexes, avec des méthodes projet cycle en V qui ne permettent pas des changements rapides et répétés. Mais, en fait les principes de DEVOPS sont parfaitement compatibles avec ITIL. Des déploiements rapides et répétés n’excluent pas une forme de contrôle et de validation de ces déploiements. La traçabilité et les processus d’amélioration sont importants autant chez ITIL que DEVOPS. De plus, la séparation des rôles et responsabilités reste souhaitable en DEVOPS. Bref, aucune incompatibilité entre ITIL et DEVOPS, il faut simplement n’implémenter que les processus apportant une réelle valeur.

devops-example

  • DEVOPS repose entièrement sur la communication : Non !

Bien sûr la collaboration et la communication sont des éléments importants, mais une meilleure collaboration et une meilleure communication entre les équipes ne suffira pas à surmonter tous les problèmes. Si un processus n’est pas efficace, avec l’accord et la participation de tous, il faut le modifier, l’optimiser et automatiser ce qui est possible pour l’améliorer.

  • DEVOPS ne peut pas être mis en place dans les Organisations avec des aspects règlementaires importants : Au contraire.

DEVOPS permet la traçabilité des déploiements et des actions. Les audits sur les actions réalisées sur tous les environnements sont donc possibles.

De plus, des interventions manuelles sont tout à fait possible si cela est imposé par la réglementation.

  • DEVOPS = Open Source : Non.

La communauté Open Source a favorisé l’adoption et le déploiement de DEVOPS, mais DEVOPS ne repose pas sur un choix technologique ou sur un choix d’outillage spécifique. Il est tout à fait possible de mettre en place DEVOPS quelle que soit la technologie, ou les technologies, utilisée(s) dans une organisation.

  • DEVOPS c’est la fusion des équipes DEV et OPS : Pas forcément.

C’est une possibilité managériale, mais ce n’est en rien une obligation. Les Développeurs et les Opérationnels peuvent rester dans des équipes différentes, avec des hiérarchies différentes tant que leurs objectifs sont alignés et qu’ils sont amenés à communiquer de manière fluide. Mais rien n’empêche non plus cette fusion des équipes.

Par contre, si fusion des équipes il y a, il faut que les rôles de chacun reste bien distincts. Le développeur doit continuer à développer et l’opérationnel à opérer. Une confusion des rôles est dangereuse. DEVOPS est donc tout à fait en accord avec ITIL sur ce point là.

  • DEVOPS est la victoire des Développeurs sur les Opérationnels : Non.

Une telle vision perpétue la vieille habitude d’opposition de ces deux mondes. DEVOPS, c’est la communication et la collaboration de chacun. Ce n’est en aucun cas une guerre de pouvoir. DEVOPS permet aux opérationnels de sortir de la situation peu enviable où ils se trouvent : ils sont en bout de chaîne et sont la dernière variable d’ajustement des projets. Bref, ils ont énormément à gagner à la mise en place de DEVOPS.

Cloud

DEVOPS n’est possible que dans le Cloud : Non.

Une organisation peut tout à fait décider de mettre DEVOPS en place en utilisant des infrastructures privées. Bien sûr, le Cloud est compatible avec DEVOPS, il est même orienté DEVOPS et en facilite grandement certains principes : notamment la mise en place et le dimensionnement des environnements. Mais rien n’oblige à utiliser le Cloud pour mettre en place DEVOPS.

  • DEVOPS est incompatible avec l’outsourcing : Non.

En fait, il faut simplement s’assurer que les pratiques de développement des externes soient compatibles avec les pratiques internes.

  • DEVOPS signifie Déploiement Continu des Développements en Production : Non, pas forcément.

Bien sûr, DEVOPS permet de déployer les applications aussi souvent que souhaité en production. Cela permet à certains, notamment les leaders du Web, de faire plusieurs changements par jour sur leurs applications en production. Certains en éprouvent même de la fierté. Mais en fait, un rythme bien moindre est tout à fait acceptable. Il faut simplement que les déploiements soient suffisamment réguliers pour que la pratique de déploiement soit fluide, mais la fréquence acceptable dépend de chaque organisation.

Share