Au début des années 2000, les ingénieurs fraîchement diplômés multipliaient les sujets d’intérêt. A la faveur de la révolution technologique en cours, certaines thématiques restaient dans le domaine de l’abstraction engendrant parfois des discussions philosophiques.

Prenons l’exemple du « Web 2.0 ». A quoi cela faisait-il concrètement référence ? Il n’était pas rare de trouver quelqu’un qui au travers d’un blog, d’une interview, d’une tribune, affirmait que tout ce que l’on savait du Web 2.0 était faux. A l’époque on pouvait lire pléthore de contenus vantant les avantages de tel fournisseur ou servant de faire-valoir à leur auteur, au lieu de clarifier pour de bon la véritable nature du Web 2.0.

Ce même schéma semble se répéter avec DevOps. Des articles aux titres racoleurs sont publiés de manière quasi quotidienne : « Ceci n’est PAS DevOps », « Ne vous y trompez pas, DevOps n’a rien à voir avec cette approche » ou « Le déploiement continu ne se pratique pas de cette manière », etc.

Si l’intention est louable et l’analyse plutôt fine, ces articles ne sont au final pas très utiles. Ils ajoutent même de la confusion dans un contexte où les entreprises ont plutôt besoin d’être confortés dans leurs projets de transformation numérique pour les mener à bien.

L’approche DevOps doit rester simple

Pour dire les choses simplement : DevOps efface les silos au sein des environnements IT. Pour comprendre ces silos, il suffit de constater que les équipes sont le plus souvent organisées de manière verticale : ingénierie, contrôle qualité, IT, achats, produits, etc.
Chaque service fonctionne avec ses propres règles et ses « interfaces » qui conditionnent la façon dont les développeurs poussent le nouveau code vers les environnements de QA (Contrôle qualité ou Quality Assurance), comment et quand ce code peut être basculé en production, etc.

Un autre type d’organisation consiste à imaginer des découpages horizontaux de ces équipes, dédiées au développement d’un même produit. L’équipe A est ainsi responsable de la réussite du produit A. Ses membres définissent les conditions de leur collaboration et de la mise en commun de l’expertise.
Dans certaines entreprises, des rôles seront fusionnés, dans d’autres ils resteront distincts mais cela importe peu : les entreprises sont réellement engagées dans une démarche DevOps quand leurs collaborateurs considèrent qu’ils appartiennent d’abord à une équipe produit avant d’appartenir à un service.

A partir de là, l’entreprise peut utiliser l’outil A ou l’outil B avec la méthodologie de son choix. La bonne étant celle qui correspond à l’ADN de l’entreprise et qui alimente la bonne dynamique DevOps. Au final, les entreprises n’ont pas à se soucier de ce qu’est l’approche DevOps ou de ce qu’elle n’est pas, car ce qui compte, c’est le changement de comportement qu’elle induit.

CI/CD

Un autre sujet de conversation récurrent concerne l’intégration / le déploiement continus (CI/CD). Où commence CD, où finit CI ? Qu’est-ce que CD, concrètement ? De nouveau, là n’est pas la question. L’approche « continue » consiste à déployer rapidement, ce qui engendre naturellement des frictions, qu’il convient logiquement de supprimer grâce à l’automatisation.

Pour qu’un process s’effectue en continu, il est nécessaire d’utiliser l’automatisation. Mais dans les faits, il est rare que le processus soit automatisé d’emblée. Pourquoi ? Parfois, le projet est difficile à automatiser ou des frictions internes existent entre les services (ex, l’entreprise continue sa progression vers une démarche DevOps, ce qui demande des efforts constants), si bien que l’automatisation se fait par étapes.

Souvent, il est plus facile d’automatiser la partie « gauche » du processus car depuis plus de dix ans, les outils de développement sont tous créés dans une optique d’automatisation.

Cette partie concerne « l’intégration continue » ou « CI ». Plus l’automatisation tend vers la droite, plus elle se mue en « déploiement continu » (CD). Techniquement, en déploiement continu, les entreprises sont constamment prêtes à déployer. Les équipes sont libres de pousser les nouvelles mises à jour vers l’environnement de production chaque fois que nécessaire.
Elles sont également en position de ne pas le faire si cela s’impose, soit parce que la mise à jour n’apporte rien d’essentiel ou parce qu’il n’est pas possible de la déployer en raison du domaine (par exemple, charger une application dans un app store ou mettre à jour des appareils physiques, comme des équipements médicaux).

L’idée est que les équipes puissent automatiser autant qu’elles le souhaitent jusqu’à l’aboutissement du projet. Pour aller plus loin, les entreprises peuvent adopter une approche de production continue, où les éléments sont effectivement basculés « en production » (ex. sur un serveur, sur un terminal, dans un app store) à chaque commit effectué.
La production continue suppose que le système sache gérer le « dernier tronçon » jusqu’au serveur/terminal/app store ciblé, mesurer l’impact et effectuer un retour en arrière en cas de problème, etc. Dans cette approche, l’idée n’est pas de penser en termes de « bon ou mauvais », mais en termes de « chemin et expérience ».

Des approches différentes

Que penser de l’automatisation des versions des applications, ARA (application release automation), ou de l’orchestration des versions des applications, ARO (application release orchestration) ? Est-ce comparable au déploiement continu (CD) ?

N’oubliez pas qu’il existe différentes approches en matière de CD qui vont de l’utilisation d’outils tels que Chef/Puppet jusqu’à l’utilisation de scripts développés en interne.

ARA est une autre approche du déploiement continu et de la production continue (Forrester désigne l’approche ARA par l’acronyme CDRA « Continuous Delivery and Release Automation » autrement dit déploiement continu et automatisation des versions). Celle-ci permet à des entreprises dont les opérations sont plus formelles d’adopter le processus de CD. Ces opérations, en plus d’être prévisibles doivent pouvoir être auditées, assorties de validations officielles dans le cadre d’une coordination entre plusieurs équipes.
Les entreprises où la partie « Ops » se charge de la distribution des versions préféreront ARA/ARO, celles où la partie « Dev » prédomine préféreront les solutions de type Jenkins X.

Il faut bien comprendre que les articles et les discussions stériles risquent d’entamer la confiance des équipes. Une entreprise qui vise une amélioration continue de ses produits et services en favorisant la collaboration, les déploiements rapides et l’automatisation est sur la bonne voie quel que soit la démarche choisie