Des principes antagonistes : DevOps contre ITIL
Auteurs : John Tran et Dipanjan Ghanti
Source : Conflicting Principles; DevOps VS ITIL
Date : 20/05/2019
Traducteur : Fabrice Aimetti
Date : 09/04/2020
Traduction :
Dans cet article, John Tran et Dipanjan Ghanti, responsables du développement, comparent DevOps et ITIL tout en offrant des conseils utiles pour une transformation réussie vers DevOps.
Sommaire
Introduction
Si vous travaillez dans une grande entreprise, des activités telles que DevOps et Agile peuvent être accueillies avec un certain scepticisme. Ces mots à la mode circulent et influencent les équipes pour changer leurs méthodes de travail, mais comment réussir la transition d'une organisation qui a beaucoup investi dans un processus séquentiel structuré et des pratiques telles qu'ITIL ? La question est plutôt de savoir si ITIL peut être décliné pour s'adapter à DevOps ?
En apparence, DevOps et ITIL semblent être des pratiques opposées, la première étant plus utilisée dans le travail de développement et la seconde dans les services d'exploitation. Cependant, si nous examinons leurs fondements, vous constaterez que DevOps ne peut pas exister globalement sans un framework tel qu'ITIL. Cet article tentera de montrer les similitudes entre DevOps et ITIL et tentera de définir une feuille de route pour que les organisations travaillent à l'adoption de DevOps et progressent dans leur manière de fournir la valeur.
Comment ITIL peut compléter DevOps
Si l'on se réfère à l'ancienne approche, le développement logiciel a été effectué en suivant les pratiques du cycle de développement logiciel (SDLC) et les pratiques de gestion de projet du cycle en V. Côté exploitation, les processus étaient régis par ITIL. Grâce à DevOps, le développement et l'exploitation se sont réunis sous une seule bannière et dans ce contexte, la méthode du cycle en V a laissé la place aux méthodes Agile. Cependant, on ne comprenait pas suffisamment comment ITIL allait entrer dans le monde du DevOps. Ainsi, à l'avènement de DevOps, beaucoup ont considéré que cela marquerait la fin d'ITIL. C'est tout simplement du vent. Comme nous le savons, DevOps n'est pas un framework, c'est plutôt un ensemble de bonnes pratiques. Ainsi, si les processus sont réorganisés avec DevOps, ils répondront aux nouveaux objectifs.
La clé du succès
Le but ultime est d'intégrer les pratiques de DevOps dans votre entreprise sans perturber le système ITIL existant. En apparence, les objectifs de chaque système sont très similaires, mais ces deux paradigmes différents peuvent être très conflictuels. Les frictions peuvent être causées par un malentendu et/ou une résistance au changement. Par exemple, les praticiens de DevOps peuvent penser qu'ITIL est trop restrictif et fastidieux ; tandis que les équipes qui pratiquent ITIL, voient DevOps comme le Far West, sans structure ni règles. Pour réussir, nous devons mettre en oeuvre des processus qui adoptent ces deux philosophies.
Les premières étapes de l'adoption
Maturité de base :
Appréhendez le niveau de maturité de référence de l'organisation. Prenez du recul, passez en revue et documentez tous les processus qui sont actuellement pratiqués. Comprendre où nous avons commencé nous permettra de mieux définir les prochaines étapes et de mesurer le succès.
Réglage du niveau, définitions :
Commencez par donner à tous les membres de l'équipe un même niveau de connaissance. Assurez-vous que chaque membre de l'équipe accepte la transformation et que chacun travaille à la réalisation des mêmes objectifs. Nous voulons inclure tous les rôles, du management, du métier, du développement, de l'exploitation, de la sécurité, de l'assurance qualité (QA), des analystes métier, etc.
Adoption et intégration :
En utilisant la maturité de référence, nous voulons identifier les domaines que nous devons développer ou les moindres lacunes dans les processus. Ce sont les domaines que nous voulons prioriser et sur lesquels nous voulons nous concentrer en premier lieu. Commencez par examiner les processus existants et voyez où de petits changements simples peuvent être intégrés en premier lieu. N'essayez pas de mettre en oeuvre DevOps en une fois. Cette approche est vouée à l'échec. La transformation doit se faire de manière organique et la culture aura besoin de temps pour s'adapter.
Par exemple, des pratiques telles que l'intégration continue (CI) et la livraison continue (CD) peuvent ne pas convenir à l'organisation et n'ont pas besoin d'être mises en oeuvre d'emblée. Commencez par l'automatisation du build et du déploiement, même si ces builds sont déclenchés manuellement. Au fil du temps, vous affinerez et améliorerez ces pratiques jusqu'à ce que l'équipe soit suffisamment mûre pour déployer de manière totalement autonome.
Amélioration continue.
L'amélioration continue basée sur un apprentissage validé est un élément essentiel des deux frameworks. En prenant des décisions basées sur des indicateurs, nous pouvons nous assurer que les changements que nous mettons en oeuvre sont un bénéfice pour l'équipe et l'organisation. Avec le temps, la maturité va augmenter et se transformer en quelque chose de complètement nouveau.
Conclusion
Dans les grandes organisations, lors de livraisons très stressantes et urgentes, les équipes contournent parfois les processus pour respecter des échéances non négociables. C'est de là que vient la mauvaise réputation de DevOps. Dans cette même situation, le processus ITIL traditionnel peut être considéré comme une entrave, n'apportant aucune valeur ajoutée à l'équipe de livraison. En fait, en mettant en oeuvre certaines des pratiques de DevOps dans les processus déjà établis de votre organisation, vous pouvez contribuer à accélérer la livraison, à accroître la qualité et à constituer une équipe plus forte et plus dynamique.
L'idée fausse selon laquelle DevOps est réservé aux petites équipes et organisations doit être changée. Les grandes organisations dont les processus sont bien établis peuvent également adopter les principes de DevOps dans leurs processus sans rejeter complètement ce qu'elles ont déjà mis en place. Pour réussir, nous devons mettre en place un processus qui embrasse les deux philosophies. DevOps est largement considéré comme un remplaçant d'ITIL, mais ce n'est pas le cas. Les choses ne sont pas aussi binaires.
Culture DevOps + framework clairement défini = Succès
