LabZoom : déploiement continu – processus et démarche ultime

Chez les grands du web, cela n’étonne personne de voir un responsable marketing s’informer auprès d’un dev’ de la progression de certains tests fonctionnels et de discuter avec lui des derniers métriques de performance commerciale. C’est tout à fait normal, ils ont poussé la logique DevOps jusqu’au bout.

Gérer le versionning… DevOps !

2009, ou DevOps 1.0. L’idée apparaît et s’infiltre dans nombre d’organisations que le time-to-market pourrait être grandement amélioré si les équipes de développeurs et les équipes d’opérationnels travaillaient mieux ensemble. Une méthode de travail qui demande une organisation d’une grande souplesse, ce que les startups peuvent offrir. Mais les grandes entreprises ne sont pas en reste et s’efforcent d’insuffler une nouvelle dynamique au sein des départements IT.

Les équipes techniques sont alors réunies autour de projets et certains explorent les avantages de l’architecture micro-services, qui repose sur les technologies de conteneurs de type Docker.

À ce stade, déjà, un pas de géant est franchi car intégration et déploiement sont automatisés,
l’organisation en projet est industrialisée et Dev’ et Ops’ poursuivent un but commun, sans que les évolutions apportées par les premiers ne déstabilisent les seconds, qui auront intégré dès l’amont les changements d’architecture ou pris en compte les nouveaux besoins applicatifs. Bref, c’est à se demander pourquoi le silo a connu de si longues heures de gloire.

En devenant complémentaires, Dev’ et Ops’ ouvrent la voie à l’automatisation accrue des processus. Dès lors le DevOps se fait 2.0 et c’est affaire de sponsoring fort, car les équipes techniques ne sont plus seules dans la danse.

Accélération du marché et entrée des métiers dans le jeu

Prenons un exemple très concret. Combien de DSI ont découvert le jour même que l’entreprise organisait un événement promotionnel d’envergure et prompte à générer une montée en charge des serveurs ? Combien de directions marketing n’ont pas imaginé devoir évaluer l’impact sur l’infrastructure d’une opération de communication ? Combien sont-ils à s’être croisés dans les couloirs sans même penser à en parler ?

Typique des organisations traditionnelles, cet état de fait tend à disparaître au profit d’une meilleure intégration des problématiques dans les objectifs communs. La démarche DevOps encourage les équipes à partager des indicateurs qui leur étaient jusqu’ici inconnus. Qu’une DSI se félicite d’abord d’un résultat égal à x commandes par minute à l’occasion des soldes plutôt que du temps de réponse d’une fonctionnalité ou de la quantité de mémoire vive utilisée, témoigne d’une nouvelle perspective dans la façon de travailler de chacun.

L’inverse doit être vrai également. Les métiers doivent comprendre que pour que l’entreprise parvienne au déploiement continu, leur rôle dans le processus devient majeur, car il conditionne l’automatisation de la mise en production, celle qui semble si difficile à mettre en oeuvre. Mais ici encore, plusieurs outils sont disponibles pour lever les freins.

À commencer par les features flag, qui permettent d’accélérer le déploiement du code en production sans être limité par des fonctionnalités encore en cours de développement, tout en autorisant un rapide retour en arrière. Les métiers peuvent se charger de certaines bascules, à leur gré en fonction de leurs besoins. Pour tous ceux qui se demandent comment fait Amazon pour déployer plusieurs fois par jour de nouvelles versions, et bien les features flag sont un de leurs secrets de fabrication.

In fine, l’intérêt principal d’une telle démarche est bien de rester au plus près des besoins des clients, qu’ils soient internes, comme la direction marketing, ou externes, tout en réduisant les coûts, les erreurs et donc le stress.