DevOps est la contraction de développement et exploitation (Developments & Operations).
Il s’agit d’un ensemble de bonnes pratiques pour mener à bien la réalisation et l’utilisation d’une application logicielle. Nous verrons dans une seconde partie qu’il est possible d’étendre cette idée du logiciel au delà de cette vision un peu trop focalisée sur la technique. Mais pour l’instant, je vous propose de faire un tour des fondamentaux.
Peut être considèrerez vous la plupart des bonnes pratiques évoquées dans cet article ou dans vos recherches futurs comme relevant du bon sens, mais vous trouverez certainement de nouvelles voies à explorer pour parfaire votre approche. Cette méthodologie se couple parfaitement à l’utilisation d’un Kanban car elle est favorable à des cycles de développements courts et d’exploitation rapide du résultat. Ce principe a pour nom l’intégration continue.
Un exemple d’objectif atteignable à l’aide de DevOps est de déployer en production le correctif d’un bug en moins d’une heure après la résolution du problème (tests unitaires, fonctionnels et d’intégrations compris).
Impliquer l’exploitation durant les phases de développement
Selon l’état d’esprit DevOps, le développeur doit penser aux fonctionnalités qu’il va mettre à disposition de l’exploitation pour faciliter la mise en place et la maintenabilité de son application.
D’un autre côté, l’intégrateur ne doit pas se sentir isolé en bout de chaine, à devoir intégrer comme il peut des briques logicielles de couleurs (technologies) et de tailles (déploiements) différentes, au risque de réaliser un puzzle immonde (performances médiocres).
Pour suivre la méthodologie DevOps, la DSI doit afficher une réelle volonté de lier fortement les entités de réalisation et d’intégration afin de les rendre plus coopérative, de les encourager à la discussion et aux échanges. S’il ne le fait pas, il se risque à des opérations de guérilla émergentes, ou pire, à un départ de ses équipes vers des DSI plus ouvertes aux méthodologies modernes.
S’il est vrai que le temps nécessaire à la réalisation de ces fonctionnalités techniques et traces “non demandées par le client” peut être perçu comme une charge supplémentaire, les expériences passées ont montré qu’éviter ce travail donne de nombreux aller-retours incontrôlés au moment de l’intégration de l’application au sein du système d’information. Selon les préconisations DevOps, une bonne coopération peut réduire ce délai d’intégration à un minimum maitrisé. Il faut donc voir tout travail sur la qualité comme un investissement, et non pas une charge de travail supplémentaire sur le présent.
Faire coopérer les métiers pour gagner en valeur ajoutée
- Le développeur apprendra à anticiper la phase d’intégration en se rendant disponible,
- L’intégrateur apprendra à remonter ses problématiques d’intégration aux développeurs,
- Le responsable de projet apprendra pour sa part à gérer son Kanban, afin de détecter au besoin les goulots d’étranglement et favoriser leur élimination.
Ainsi fluidifiée, des phases courtes de déploiement donnent deux avantages stratégiques au management :
- En amont : reconcentrer les équipes sur la création de valeur : architecture technique et usage des IHM, documentation des manuels utilisateurs dynamiques (infos bulles, wiki, … ), mise en place des logs fonctionnels au même titre que des logs techniques, afin de permettre les actions en aval.
- En aval : assurer la haute disponibilité : connaitre la qualité de service sur le terrain et planifier l’évolution des besoins courants (croissances utilisateurs, volumes, …), anticiper les montées en charges (désactivation des options gourmandes en ressources …), moduler les services en fonction de l’utilisateur connecté (tests et statistiques), remonter problématiques afin de les régler en phases amont pour la prochaine livraison.
Vous pouvez constater que DevOps rend interdépendante les phases de développement et d’exploitation, et c’est au responsable de projet de mettre à disposition les moyens nécessaires à la réussite du projet.
Nous verrons dans la deuxième partie comment étendre les préconisations DevOps aux phases de conceptions et de recette d’un projet logiciel.
