+33 (0)1 69 33 05 50

Actualité et agenda de l'AFTI

DevOps - CFA AFTI

Le DevOps : au-delà du buzz, une méthode qui a du sens

Le DevOps, comme tous ces mots de management tendance venant des États-Unis, est très vite mentionné dans les conversations d’initiés, mais souvent incompris. Utilisés à tort et à travers et désignés comme évolution disruptive de nos méthodes actuelles, peu sont ceux qui évoquent les lourdes transformations internes que cette méthode exige, aussi bien techniques qu’organisationnelles. On fait le point sur le sujet avec vous.

Au commencement, il y avait des retards

Dans les années 1990, une entreprise mettait au moins 3 ans pour imaginer, créer, et intégrer une application logicielle. Ce délai doublait dans les secteurs banquiers ou automobile, voire triplait pour le secteur aéronautique. Un temps de mise en production effarant de nos jours, où un simple algorithme devient dépassé en quelques mois. L’évolution technologique était moins flagrante auparavant, mais cela restait tout de même trop long pour que l’outil, une fois installé, soit à la hauteur des nouvelles attentes technologiques du client. Beaucoup de développeurs ont cherché à réduire ce temps de développement, notamment en morcelant les fonctionnalités et en les intégrant une par une, afin de pouvoir s’adapter rapidement en cas de changement.

C’est par ce besoin qu’est née la méthode agile en 2001, après la création du Manifeste de l’Agilité, page web biblique regroupant 12 principes majeurs à la pratique du développement logiciel par incrémentation. Suite à l’efficacité prouvée de cette méthode, le DevOps est né peu de temps après en 2009, en reprenant ces principes. Par DevOps, on comprend une méthode rapprochant les « Devs », créateurs du produit, et les « Ops », intégrateur de ce produit dans son environnement. Le but du DevOps est de répondre à un besoin de développement et d’intégration plus rapide, et donc d’une collaboration plus large entre les « Devs » et les « Ops ». Plus qu’une adaptation à une méthode, le DevOps requiert une adhésion philosophique.

Tu adopteras les principes de l’Agilité

Les anciennes méthodes de développement, et donc implicitement de management, séparaient complètement les pôles des Devs, créateurs du code applicatif, et des Ops, garants de l’intégration de ce code à une machine, quelle qu’elle soit. Ceux-ci avaient pourtant un objectif bien distinct : les « Devs » devaient créer un code remplissant les besoins fonctionnels du client dans un temps limité, et l’« Ops » garantissait la stabilité du système en cours. Les responsabilités en cas de délais, de fonctionnalités défectueuses, ou même d’échec d’intégration valsaient souvent entre ces deux pôles. Le DevOps est là pour renouer l’amitié entre ces pôles, pour un workflow plus efficace, plus productif, et plus transparent. Tout comme dans la méthode agile, chaque faute est imposée à un groupe, et non à l’individu. Chacun est garant, pas seulement du travail qu’il accomplit, mais aussi celui de ses collaborateurs. Toute information concernant le projet est partagée au sein de l’équipe. Tout changement qui vise à améliorer la productivité souhaitée doit être accueilli. Le seul objectif est la satisfaction du client. Bref, en DevOps, un changement de mentalité est requis. Mais la particularité du DevOps ne se situe pas tant dans son idéologie, que dans son organisation que des outils qui en découlent.

Le DevOps créa l’automation, et vit que c’était bien

Si l’on applique l’idée d’intégration cyclique, on pourrait penser à une multiplication du nombre d’intégrations, et donc une surcharge de travail pour les Opérationnels. C’est en fait tout l’inverse ! Le développement s’effectue directement sur une machine virtuelle, et est appliqué, testé, diagnostiqué en temps réel grâce à des logiciels comme jenkins ou travis. La transition sur le serveur client est elle aussi automatisée par puppet ou ansible, le tout configuré par les Ops. Vous l’aurez compris, travailler en DevOps signifie automatiser la majeure partie de la création à l’intégration, pour que les Ops puissent s’atteler à l’amélioration du service rendu (monitoring, hardware, sécurité), et que les Devs puissent coder en continu. L’implication du Devs étant plus poussé qu’auparavant, l’équipe doit se prémunir d’une organisation spécifique pour pouvoir coder collaborativement, et traduire le langage s’il le faut. Le Dev doit parfois élargir son champ de connaissances sur l’infrastructure, ou les langages utilisés pour mieux s’intégrer au nouveau fonctionnement de l’équipe, tout comme l’Ops doit s’intéresser aux langages de codage.

N’oubliez pas que la structure de l’entreprise, et surtout de l’équipe, modifiera en conséquence l’organisation de votre équipe. Tout comme la méthode agile, le DevOps n’est pas une fin en soi. Et son adoption, elle, n’est pas automatique ! Tout changement, qu’il soit organisationnel, philosophique ou technique, prend du temps. Le plus important est d’adopter une bonne posture face à celui-ci.