Cette année, la Société Générale a choisi de faire une présentation appelée « L’odyssée du Continuous Delivery ». Nicolas Bourgeois, Diego Lemos et David Caramelo nous racontent comment ils transforment une équipe de 70 personnes sur 2 continents depuis 2014.
La Société Générale sponsorise Devoxx depuis plusieurs années et fait partie de ces grandes entreprises qui ont compris que le métier de développeur devait évoluer. Depuis plus de 2 ans la SG a pris le virage du Software Craftsmanship et du DevOps en transformant l’ensemble de sa DSI grâce au programme Continuous Delivery impliquant près de 40 coachs agile, craft et devops.
Dans ce cadre Xebia accompagne la SGCIB dans sa transformation et nous sommes fiers de partager avec eux cette expérience à travers cette présentation sur « L’odyssée du Continuous Delivery ».
Si demain, Google investit votre secteur de marché, survivrez-vous ? Aujourd’hui, les GAFA mettent au défi les entreprises traditionnelles. C’est l’heure de la remise en question et certains dirigeants l’ont bien compris.
Les enjeux de l’IT d’aujourd’hui résident dans sa capacité à créer des produits et à les adapter pour répondre à des besoins dont la valeur se situe de plus en plus dans l’instant. C’est un travail pour lequel elle doit faire preuve d’une vitesse et d’une efficacité d’exécution croissante. Face à ce défi, elle est confrontée à des challenges à la fois technologiques et humains. C’est en substance le discours diffusé par Carlos Goncalves, DSI de la SGCIB qui mène depuis 3 ans un important programme nommé Continuous Delivery.
Nicolas, application manager à la SGCIB, nous explique combien cette transformation était devenue nécessaire. Les crises financières ont empêché les investissements depuis plusieurs années et la plateforme était vieillissante. Avec la reprise de l’activité, il fallait investir dans une nouvelle plateforme avec une nouvelle obsession : la réactivité. En effet, il est illusoire de vouloir répondre à la pression FinTech avec des architectures et des organisations traditionnelles.
Pour relever ce challenge d’ampleur, Nicolas nous explique qu’il a fallu recruter des gens capables d’aider à utiliser les nouvelles technologies et les nouvelles méthodes. L’arrivée de Diego et de David s’inscrivait précisément dans cette optique. Il insiste aussi sur le fait qu’il a fallu grossir vite tout en livrant de la valeur rapidement. Ils se devaient d’avoir les moyens d’augmenter rapidement le nombre de livraisons dans un environnement habitué jusque-là à livrer tous les trimestres. Une évolution qui devait se faire dans un contexte de maintenance du service et sans perdre de vue l’importance de faire une plateforme en rupture technique et sans bigbang. C’est pour répondre à ces challenges que Nicolas avec l’aide des coaches a organisé ses équipes en feature team.
Diego Lemos est coach tech chez Xebia, il intervient dans les équipes du périmètre depuis 1 an en tant que coach craft. Il décrit son rôle nouveau dans la structure : faire monter en compétence les développeurs pour en faire des craftsmen, des développeurs pragmatiques, maîtrisant les méthodes de développement et le travail en équipe.
Durant cette année passée dans l’équipe, il décrit plusieurs étapes. La première étant la prise en compte de la dette technique, pour faire du Continuous Delivery, il faut aller vite, la dette technique est un frein à la vitesse de développement. Diego est arrivé dans les équipes avec une boîte à outils souvent inconnus dans ces structures : les coding dojo pour entraîner les développeurs, l’apprentissage du Clean Code, TDD, du BDD, du DDD et la mise en place des revues de code. Au-delà d’un nouveau vocabulaire, il s’agit avant tout d’une nouvelle façon de travailler !
Une problématiques récurrente qui empêche l’adoption du Continuous Delivery est l’ampleur de la dette technique qui doit être adressée. Payer la dette en best effort n’est pas possible et le constat est assez rapidement établit. Nicolas explique qu’ils sont allés voir le métier pour trouver le financement et, avec de bons arguments, ont obtenu qu’environ 20% du temps soit dédié à payer la dette (et aussi à faire de l’amélioration continue). C’est une première victoire…
Ensuite, il a fallu changer de façon de travailler. La définition d’une nouvelle stratégie de branches en est un exemple marquant. Les équipes sont passées de 192 branches sur 10 applications à une seule (trunk based) par application !
La communication entre les équipes a été aussi une préoccupation prioritaires. Diego explique comment la mise en place d’un release train « à la Spotify » a permis de faire vivre ensemble plusieurs équipes avec des contextes et des niveaux de maturité différents.
Un marché noir des environnements
La gestion des environnements a dû également être retravaillée pour livrer des fonctionnalités de manière fluide avec des dépendances dans une chaîne applicative. A l’époque, la disponibilité des environnements était tellement problématique qu’il existait un véritable marché noir des environnements ! Les équipes se prêtaient les environnements en fonction du planning : « je te prête mon UAT cette semaine, tu me prêtes ton intégration la semaine prochaine ».
Pour répondre à cette problématique, les équipes ont automatisé les déploiements et mis en place un pipeline d’environnement.
David était Scrum master d’une des équipes. Son intervention est un retour d’expérience du point de vue d’une feature team. Comment il a accompagné ces coéquipiers pour apprendre à devenir agile, comment il a amélioré peu à peu son whiteboard et veillé à son amélioration continue. David nous explique leur stratégie pour faire grossir les équipes tout en assurant la montée en compétence. Ils ont adopté un mécanisme de mitose : on double les rôles dans l’équipe, on continue à travailler dans cette grosse feature team puis on la scinde en 2 équipes autonomes capable de prendre n’importe quel sujet.
Le toggle feature, pas à pas
David et Diego nous expliquent ensuite comment l’implémentation du toggle feature a permis à leur équipe de travailler sereinement en limitant les dépendances avec les autres équipes. Toute cette organisation ne s’est pas faite en un jour, les équipes sont dans une démarche d’amélioration continue et sont accompagnés par un coach technique. Au départ le toggle feature n’était même effectué qu’en commentant le code, tout simplement. Par la suite l’utilisation d’XL Deploy a permis d’automatiser les déploiements. Aujourd’hui les équipes travaillent sur la mise en place de FF4J pour améliorer encore le mécanisme.
On a appris beaucoup de choses, on va pas recommencer à chaque recrutement…
Le constat est clair : l’équipe a beaucoup appris sur le chemin du Continuous Delivery, pour continuer à produire l’équipe doit minimiser le temps d’intégration des nouveaux arrivants. Cela dans le but de recruter des têtes bien faites plutôt que bien pleines. Les équipes ont changé radicalement les entretiens de recrutements, les nouveaux arrivants font des katas : des exercices de code sur le clavier où l’ont va regarder les connaissances bien sûr mais aussi la réflexion, l’aisance au clavier, le discours…
Un état des lieux très positif
Pour Nicolas les résultats sont évidents : nouvelle culture, amélioration continue, chaque nouveau est sélectionné pour accélérer le mouvement, c’est un cercle vertueux et ça se voit. L’amélioration est globale, il y a de moins en moins de bugs. La réduction du time to market est avérée et le métier se rapproche de l’IT.
Conscient qu’il ne faut pas s’arrêter en chemin et que des nouveaux défis sont d’ores et déjà à adresser : mieux mesurer la valeur métier, le monitoring, l’exploration et le comportement des utilisateurs. Il faut aussi renforcer la culture et trouver les leviers pour avoir le même niveau de compétence à l’étranger. Pour y arriver, les nouveaux chantiers tournent autour de l’infra as code, du blue/green deployment et encore de nombreux sujets très colorés DevOps.
Les slides de la présentation sur Devoxx – 2016 – L’odysse du Continuous Delivery
Retrouvez les retours des xebians sur la conférence: