Connaissez-vous l'ODD (Ops Driven Development) ?

La réponse est forcément non, car je viens de l'inventer (ou alors vous retombez sur cette article plusieurs années après).

Vous connaissez certainement le TDD (Test-Driven Development) qui préconise d'écrire les tests unitaires avant d'écrire le code.

Le BDD (Behavior Driven Development), conçu par Dan North en réponse au TDD.

Mais puisque la recette magique n'était pas parfaite, le MDD (Model Driven Development) a été pensé pour permettre de développer rapidement, efficacement et à pas cher (non rien à voir avec la publicité MAAF). C'est en fait du MDSD ou du MDA (vous commencez en avoir marre de tous ces acronymes ?).

Le problème, c'est que l'informatique c'est développée de façon exponentielle (peut-être que finalement c'est logarithmique) et les architectures ont complètement changées (en fait pas tant que ça, mais faut bien vendre).
Avec l'apparition des architectures de plus en plus complexe, comme l'architecture micro-services, Eric Evans a décrit l'approche DDD (Domain Driven Design).

Vous aurez certainement remarqué, l'informatique aime bien tous les acronymes qui terminent par DD (serait-ce en hommage à feu le jeu à gratter Dédé ?)

Le constat

Avec l'expérience, je me suis aperçu que beaucoup de développeurs, chef de projet, directeur de projet, Product-Owner… ne se concentraient que sur un élément du cycle de vie d’une application.

Par exemple, j’ai vu un développeur mettre en place un appel de service sans permettre la possibilité de passer par un proxy (ce n’est pas un dénigrement, c’est un constat).

Quelques-uns s'intéressent à comment automatiser le build et les tests pour garantir une bonne qualité de code, livrables...

Très peu d'entre-deux s'intéressent à la vie après le dev.

Lorsque vous en trouvez, c'est formidable mais beaucoup encore s'arrêtent à la phase d'intégration ou recette (quelqu'un pourras un jour m'expliquer vraiment l'intérêt de ses environnements qui se disent approcher de la prod mais qui en sont très loin ?).

Quelques élus s'intéressent aux tests de charges, ce qui est quand même bien. Généralement ces personnes sont isolées dans des Directions Techniques (afin de bien cloisonner l'entreprise).

Du coup, les plateformes de pré-prod, les prod à blanc (ou les architectures blue/green) et la prod sont inconnues (il y a plus de chance pour les développeurs de rencontrer des extra-terrestres).

Les seuls qui ont voulus s'y intéresser ont été coulé dans du béton mental.

Qu'est-ce que l’ODD ?

L’ODD c'est ma contribution à la popularisation du DevOps. Donc, oui, l'ODD permet de parler du DevOps dans les milieux autorisés qui s'autorise à penser.

Puisqu'il faut des méthodologies ou je ne sais quoi, pour que les choses se fassent, je me suis dit qu'en créant l’ODD, ça allait faire du buzzword.

L'ODD c'est prendre en compte toute la vie de l'application, pas seulement la partie Ops (production). Mais bon, si déjà on prend en compte la production dès le développement et a fortiori dès la conception, c'est déjà pas mal.

Pourquoi l'ODD concerne toute la vie du logiciel ?

Si on prend les xDD ou les méthodologies ou les approches, elles se concentrent sur un point de vue (ou un problème).

Mais finalement, si on demande aux personnes de décrire la vie et le cycle de vie d’un logiciel, il manque pas mal de partie.

Vous a-t-on déjà parlé de la fin de vie d’un logiciel ?

Voici une vie et un cycle de vie d’un logiciel :

On remarque que l’application se créer à chaque rencontre entre le métier et les techniciens et s’arrête à chaque mise en production d’une nouvelle version ou d’une nouvelle application (à moins que l’entreprise soit cessation d’activité).

Si l’application est arrêtée pour être remplacée par une autre ou pour cessation d’activité, il y faudra alors prendre en compte la conservation des données, comme lors de la création de l’application. On reste donc dans le même cycle.

Et comme la vie, lorsqu’on zoom, on s’aperçoit que la partie développement est composée de plusieurs parties comme le corps est composé d’organes, les organes composés de cellules, elles même composées d’atomes…

Y a-t-il des exemples d'ODD ou d'anti-ODD ?

Certainement, mais comme en médecine, un symptôme correspond à plusieurs maladies, une maladie peut avoir plusieurs symptômes et l'absence de symptôme n'indique pas une absence de maladie.

Quel est le problème du DevOps ?

Le problème du DevOps (comme les xDD, les approches, les concepts...) c'est qu'on améliore l'état du patient mais on ne le guérie pas. Mais comme en médecine, il y a deux choses :

1. améliorer l'état du patient (ou le stabiliser),
2. le guérir.

Il faut bien garder en tête que la prod n'est pas une finalité mais une étape dans le cycle de vie du logiciel.
Ce n'est pas l'étape la plus importante, c'est une étape tout aussi importante que les autres.

Conclusion

L'informatique n'est pas un monde à part, où les lois physiques seraient différentes.

Personne ne construit une maison en commençant pas la décoration.

L'inconvénient de l'informatique contrairement à la maçonnerie, c'est que réécrire un programme est plus simple que détruire un mur et le reconstruire.

Ce qui est logique, de bon sens dans un domaine, l'est aussi en informatique. Et l'inverse est vrai.

Une application scalable, résiliente, maintenable, rentable ne s’improvise pas, c’est un investissement.

Aujourd’hui, il n’y a plus d’options possibles en informatique. La sécurité d’une application n’est plus une option (aussi bien technique que légale), la maintenabilité n’est plus une option, la performance n’est plus une option…

Pour développer une application informatique, il faut de l'argent, de la volonté, une forte cohésion, une vision et du temps.

Quand je parle cohésion, je vais jusqu'à, dans la méthode Scrum, ne pas opposer US technique et métier.

Une US technique répond à un besoin métier, directement ou indirectement.

Une US technique est l'égale de l'US métier. Et ne pas traiter la technique à part, en mode Kanban (c'est une sorte de ségrégation).