Non, le devops n’est pas une mode !

Le terme devops est souvent utilisé dans tous les sens au sein des entreprises ; pourtant le devops n’est pas une mode. Je profite de cet article pour que vous comprenez bien ce qu’est le devops et l’apport non négligeable qu’il apporte au monde de l’agilité.

L’origine du devops

Si vous avez loupé notre article sur l’origine du devops, je vous conseille d’y jeter un oeil car il va vous éclairer sur ses raisons d’être.

Article : Il était une fois devops… Origines du devops

Le devops est une approche… Pas un ingénieur

Le « devops » est un terme devenu ultra fréquent au sein des sites d’emplois IT ou des profils Linkedin ; pourtant, nous parlons en fait « d’ingénieur devops ». Ce poste définie des ingénieurs qui ont de bonnes connaissances dans des technologies très utilisées dans l’univers devops ; elles ont énormément évolué depuis la création du terme en 2007.

Mais le devops est en réalité une approche qui veut la fin des silos entre les développeurs et les administrateurs systèmes (appelés ops en anglais)… On peut aussi parler du rapprochement des métiers : le bizops (BizDevOps).

Article : Qu’est-ce que le Bizops ?

Pourquoi le devops n’est pas une mode ?

Le devops permet le rapprochement des développeurs et des administrateurs systèmes ce qui permet de supprimer une organisation de type « unité au service de » que nous pouvons voir trop souvent dans les grandes entreprise.

Ces silos et ce type d’organisation font perdre beaucoup d’argent à l’ensemble de l’entreprise et l’empêchent de vraiment s’agiliser. Ces équipes infrastructures au service des développeurs ralentissent considérablement les mises en production et la capacité d’accélérer le TTM (time-to-market) des produits.

Je parle d’équipes infrastructures mais parfois l’entreprise impose aux équipes de développements de faire des demandes à d’autres équipes complémentaires :

• équipe sécurité
• équipe homologation (tests)
• équipe hardware (pour installer un nouvel outil)

Et malgré le fait que toutes ces unités soient de la même entreprise, les unités se facturent les services ; un coût non négligeable incroyable alors que tout le monde devrait avancer dans le même sens.

Ok, donc le devops n’est pas une mode !

Fini les silos, la constitution de feature team autonomes est une nécessité pour gagner en agilité ! Quand une équipe peut créer un produit et le livrer sans la moindre demande, on accélère considérablement la capacité de s’adapter au marché.

L’intégration continue

L’intégration continue est devenue une arme redoutable de l’univers devops. Bien que ce concept est très ancien, il a été remis en avant et au goût du jour grâce à cette approche devops.

Le fait de rajouter des tests automatisés permet de limiter au maximum les regressions futures. Il existe plusieurs types de tests comme la TDD et l’ATDD. Ce dernier permet d’automatiser des tests fonctionnels de chacune des user-stories à livrer (sans parler de l’approche qui a pour but de guider le développeur par les tests).

Avec des tests fonctionnels de qualité, les équipes d’homologation (testeurs de recette) deviennent inutiles. Plus besoin d’attendre une semaine de tests complets pour livrer le produit en production. Il sera même possible de livrer en production sans aucune intervention humaine si un système de monitoring et de rollback automatique sont en place.

Article : Quelle est la différence entre l’ATDD et la BDD ?

En effet avec une plate-forme d’intégration continue complète, il ne sera plus d’aucune utilité de solliciter les équipes infrastructures. L’équipe de développement sera 100% autonomes sur les mises en production.

Des environnements enfin équivalents

Une problématique revenait souvent dans les entreprises : comment s’assurer que ça marchera en production alors qu’il y a plus de charges et de CPU en production ?

Sans entrer dans le détail, l’approche devops amène à penser différemment. Le cloud associé à des outils d’orchestrations de conteneurs et d’outils de conteneurs (comme docker), permettent enfin d’avoir d’avoir des environnements équivalents au moindre coût que ce soit en production, en recette ou en développement.

Bien que la charge y sera différente, des nouvelles façons de développer comme les « micro-services » et les développements avec des notions de « scalabilité » (le tout en cloud) permet de supprimer la charge comme facteur de risque. Cela implique de changer radicalement les façons de faire mais donne encore plus d’agilité à l’entreprise : tester en recette assurera que ça marchera en production (le test humain n’est vraiment plus nécessaire).

Article : Mettre en place une Plateforme Microservices

Conclusion, devops n’est pas une mode

L’approche devops qui a donnée naissance (ou qui a fait revivre) à des pratiques d’excellences techniques est parfois essentiel au sein des structures qui n’arrivent pas à s’agiliser.

Ce terme parfois un peu marginalisé est en réalité une transformation indispensable à acquérir pour un grand nombre de structures. Si le scrum apporte un cadre méthodologique, le devops apporte l’excellence technique voulu par le scrum mais sur lequel il n’a pas vocation à donner de solutions.

Avec une véritable approche devops, l’entreprise aura maximiser l’accélération de son TTM et pourra faire face à la concurrence de plus en plus féroce.