/ delivery

Appdays 2017 : Portrait d'un serial builder (1/2)

Nous avons eu le plaisir de présenter une conférence aux Appdays 2017 sur la façon dont nous adressons le Continuous Delivery de nos Applications Mobiles. Nous vous proposons, avec Sébastien Pousse, de retrouver dans ces 2 billets les points clés à retenir.

Une App !

android

Nos équipes de développement réalisent l'App PagesJaunes. Elle est codée en natif sur iOS (Swift/Obj-C) comme sur Android (Java/Kotlin). Comme beaucoup d'acteurs du marché, nous avons des enjeux forts sur nos audiences, notre business, nos users.

Cela se traduit par 2 objectifs essentiels, mais contradictoires, à prendre en compte dans la façon dont nous construisons nos applications :

  • Assurer une qualité élevée sur chacune de nos releases
  • Délivrer rapidement les nouvelles fonctionnalités.

Une organisation en Features teams

Or, l'investissement sur les apps est élevé - nous sommes nombreux - et c'est un lieu commun de dire qu'il ne suffit pas de rajouter des développeurs pour accélérer de façon linéaire. Bien au contraire ! L'augmentation du nombre d'intervenants rajoute de la complexité qui est plutôt de nature à diminuer notre efficacité.

Pour répondre à nos enjeux tout en respectant nos objectifs de qualité et vélocité, nous devons donc disposer d'une organisation efficace qui s'appuie sur des plateformes techniques modernes.

appdays_team

Nous nous sommes organisés en Features Teams Agiles. L’objectif vise à ce que chaque équipe soit la plus autonome possible sur le périmètre qui lui est confié. Le modèle se veut scalable, sur les Apps nous sommes monté jusqu’à 4 équipes front avec dans chacune d’entre elles 3 devs iOS et 3 devs Android. Le résultat, c'est que nous avons aujourd’hui une application conséquente (> 100k lignes de code par plateforme) à moderniser et faire évoluer continuellement, que ce soit fonctionnellement ou techniquement (ex : notre migration Swift sur iOS).

Pour faire fonctionner cette organisation, pour faire travailler ensemble ces équipes sur le même code, et en même temps répondre à nos 2 objectifs, nous nous appuyons sur 2 piliers :

  • Nous appliquons des méthodes inspirées du Crafstmanship pour élever progressivement le niveau global des équipes de développement et assurer une logique de modernisation continue,
  • La plateforme d'intégration continue placée au coeur de notre fonctionnement.

Il y aurait beaucoup à dire sur le premier point, et nous aurons sûrement l'occasion d'y revenir ici, mais c'est bien du second dont traite la conférence. Pour mieux comprendre nos choix, remontons un peu le temps. "En route pour le 21 octobre 2015, Marty !"

tumblr_mmdvulLqSc1rvjt2vo1_500

La situation il y a 2 ans

IMG_0474

Partant de l'expérience technique sur notre site web, nous avions mis en place un develivery applicatif mobile fondé sur des outils et infrastructures partagés. Mais nous avons rapidement rencontré de nombreuses difficultés :

  • Du jenkins en maitre esclave inter site qui bagotait,
  • Un gitlab hébergé en local sur lequel nous subissions les mises à jour (Mauvaise synchro des équipes),
  • Des outils plus largement non accessible de l'extérieur,
  • Des composants faits maison que nous devions maintenir au fil de release (ex : un store interne applicatif).

Bilan : des releases qui prenaient au minimum 9 semaines, parfois 10 ou 11.

Bref, nous ne maitrisions pas vraiment nos cycles de développement, la recette attendait les builds, certains développeurs passaient leur temps à maintenir la plateforme, et les autres métiers je vous dis pas, non je vous dis pas... Quand soudain : "Maintenir une plateforme, nous les devs, on aime pas ça... Nous, ce qu'on aime, c'est Développer !" Jeffrey Macko

Il nous fallait donc une plateforme vraiment plus efficace, une plateforme spécifique à nos besoins mobiles.

La vision

vision

Désormais, nous devons nous fixer un cap ambitieux, un objectif fort, renverser la situation.

Du Continuous Deployment !!! Un jour, il faudra bien que chaque équipe puisse envoyer une version en production dès lors qu'elle a fini son travail. Nous ne pouvons plus attendre. C'est notre objectif et la plateforme technique est un enabler pour l'atteindre.

Une nouvelle stratégie

Pour commencer, nous avons choisi de prendre le contre-pied de cette situation. De changer de paradigme, avec comme règle d'or :

"Ce qui n'est pas notre métier, on ne s'en occupe pas !"

Pour chacune des difficultés rencontrées, il existe des solutions SaaS, dans le cloud, parfois spécialisées dans les Applications Mobiles. Ces solutions font très bien leur job et le feront de mieux en mieux à l'avenir.

IMG_0477

Pour le coeur de notre plateforme d'intégration continue, nous avons choisi Bitrise, qui nous a alors paru la plus en adéquation avec notre besoin : Builder, builder et encore builder !

Pour le développement, nous avons migré sous github, dans le cloud, ce qui représentait une petite révolution avec toutes les questions de sécurité qui sont apparues. Mais ça c'est un autre sujet.

Enfin, pour renforcer notre capacité à rendre les équipes plus autonomes, nous avons introduit la notion de Feature Flipping dans nos façons de coder. Le code de toute nouvelle fonctionnalité partira en prod. Simplement, il sera inactif jusqu'à ce que la feature soit terminée, c'est à dire développée, testée et qu'on a garanti qu'elle n'impactait pas la qualité globale de l'application.

C'est sur la base de ces choix et principes que notre plateforme de Continuous Delivery Mobile est née : le Build Bot Mobile !

Pour en connaitre l'anatomie, il vous suffira de patienter quelques jours puisque Sébastien vous la précisera dans la seconde partie de l'article !