Quel est le bon niveau de maturité pour le DevOps en entreprise ?

Le DevOps : une méthodologie ? Un ensemble d'outils permettant d'automatiser les processus ? Pas tout à fait...

Pour commencer, qu’est-ce que le DevOps ?

Le DevOps est avant tout une démarche collaborative ayant pour but d'améliorer la communication, en supprimant les murs dressés entre les équipes techniques d'un projet applicatif. Le DevOps, c’est faire en sorte que les développeurs qui font évoluer le produit, et les ingénieurs de production qui sont garants de la stabilité de la plateforme de production, puissent initier un dialogue dès le début d'un projet. Le but est d'avancer ensemble sur les problématiques rencontrées dans le cadre de ce projet.

LA problématique...

Malheureusement, aujourd'hui le mot DevOps est souvent galvaudé ou mal interprété par les personnes qui entendent parler de la démarche et souhaitent la mettre en place. Dans les entreprises, nous observons des degrés de maturité inégaux.

Les différents niveaux de maturité pour le DevOps

Old school

Dans la pratique, les développeurs rédigent du code et fournissent un package aux ingénieurs de production qui s'occupent du déploiement en production. Une fois leur package transféré, les développeurs clôturent le dossier. Si le client a entendu parler de la démarche DevOps, il ne sait pourtant pas exactement de quoi il s'agit, et encore moins comment la mettre en place. Néanmoins, il est au fait du gain substantiel de temps lié à l'automatisation des processus. Souvent, la notion de qualité est relative car le produit existe depuis longtemps et les standards de développement n'ont pas été remis au goût du jour. Ceci implique parfois une absence de remise en question des méthodologies employées.

Tools first

Seules les parties « gain de temps » et « qualité du produit livré » ont été retenues dans le concept de démarche DevOps, et seulement par l'équipe projet incluant le chef de projet et les développeurs. La notion de collaboration et la relation de confiance, intrinsèques au concept, sont laissées de côté. Même si les builds sont automatisés, qu'une analyse de code source est mise en place, et que chaque nouvelle fonctionnalité est validée par un pair développeur via une pull request, les ingénieurs de production refusent de déployer le produit en production de façon automatisée. Ils n'ont pas suffisamment confiance dans les développeurs et le package qu'ils leur ont fourni. Pourquoi ? Car les développeurs ne les ont que trop rarement consultés lors des prises de décisions liées à l'évolution du produit. Ainsi, de longues procédures de déploiement seront jouées manuellement par l'équipe de production sur différents environnements pour valider l'ensemble du processus de livraison et vérifier qu'aucun problème ne viendra troubler la stabilité de la plateforme de production.

DevOps Approved

Ici, tout va bien. Les équipes communiquent régulièrement et travaillent ensemble à la meilleure façon de traiter les problèmes rencontrés. Qu’ils interviennent en environnement de développement ou de production, les problèmes sont pris en compte par l’ensemble des acteurs. Chacun partage son expertise avec l’autre pour acquérir un niveau de compréhension optimal de la vision de chaque partie prenante. Les outils mis en place prennent en charge la totalité des processus pouvant être automatisés, incluant l’analyse de code source, le build, les tests fonctionnels et la livraison sur les différents environnements, allant jusqu’à la production. La relation de confiance tissée par les équipes tout au long du projet est facilitée par la communication, l'acceptation du droit à l’erreur ou encore la transparence des actes vis-à-vis des pairs. Le mindset de l’équipe est au top, les outils mis en place permettent de contrôler la chaîne de livraison automatisée allant du développement au suivi de l'application en production. Rien ne devrait empêcher l’équipe de fournir un produit de qualité de manière régulière aux clients qui bénéficient de versions prenant rapidement en compte leurs feedbacks.

Le bon niveau, c’est quoi ?

Finalement, comment définir le bon niveau de maturité qui conviendrait à une entreprise ? Remplir l’ensemble des critères, bien évidemment... Mais pas seulement. Le bon niveau de maturité est avant tout celui qui ne met pas la charrue avant les bœufs. En effet, comme expliqué dans LA problématique, les équipes galvaudent souvent le terme DevOps et ont tendance à vouloir mettre en place les outils à la mode sur le marché qui leur promettent de gagner un temps qu’elles pourraient allouer ailleurs. Les équipes oublient par la même occasion que le maître mot de la démarche DevOps est la collaboration entre les équipes. C’est pourquoi, le bon niveau de maturité dépend avant tout de la bonne compréhension du concept même de démarche DevOps et de l’utilisation qui en est faite.