/ delivery

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

Nous avons eu le plaisir de présenter une conférence aux Appdays 2017 avec Nicolas Durand sur la façon dont nous adressons le Continuous Delivery de nos Applications Mobiles. Nous avons séparé le sujet sur deux billets... la première partie se trouve ici :)

Anatomie d'un serial builder

Le BBM (Build Bot Mobile) prend tout en charge de façon automatisée. Depuis la création des plateformes en passant par la compilation des projets jusqu'au déploiement et au monitoring.

slide15-anatomie-serial-builder

Infrastructure

Les plateformes

Hors de question de maintenir une plateforme. Les serveurs sont dans le cloud. Une machine virtuelle (VM) est mise à notre disposition par le BBM à la demande et détruit à la fin de son utilisation.

Le réseau

Le réseau c'est internet. Pas de liaison inter site, pas de configuration "reverse proxy" qui disparait... Plus de friction, nous avons la maitrise du réseau. La liberté !

Les environnements

La VM est créée. Elle charge un environnement sain et identique à chaque fois. Stabilité, fiabilité. Du Linux pour la plateforme Android, du MacOSX pour la plateforme iOS.

Les logiciels

Les logiciels chargés sont standards aux OS (Linux ou MacOSX), avec bien entendu la possibilité de charger nos propres logiciels dans la version de notre choix. Cela devient assez simple du coup de tester une nouvelle version d'un compilateur: un simple numéro de version à changer, et la VM est prête... Plus qu'à tester.

La sécurité

Une de nos grosses préoccupations à été la sécurisation de nos données sensibles. Et pour cela nous avons séparé nos objectifs de développement et de production.

Pour la phase de développement, nous avons pris le postulat qu'il n'y aurait rien de critique qui transitera sur le cloud. En revanche pour le cas du build de production nous le verrons plus tard, nous avons mis une petite astuce maison en place...

Principe de fonctionnement

slide17-principe-fonctionnement

Globalement comment ca marche ? Les dev poussent leur code sur un repository, le BBM écoute l'activité du repository. Selon le type d'activité il lance un workflow spécifique à cette activité (ensemble de steps). Si tout se passe bien un build est mis à disposition sur un store interne.

Les workflows

slide18-worflows

Sur les développements nous avons décidé de cabler principalement 3 workflows.

Le premier workflow se déclenche à chaque PR (Pull Request) d'un développeur. Il va builder le projet afin de garantir la bonne intégrité du nouveau code apporté et lancer les tests unitaires associés au projet. Si c'est KO la PR est refusée, le développeur est notifié.

Si c'est OK, la PR passe et on lance le second workflow qui va générer un changelog entre la version n et n-1 et déployer le projet sur notre store interne.

Le troisième workflow quand à lui à été mis en place récemment et nous permet toutes les nuits de vérifier nos projets avec les configurations de production. En effet ce fut la source de quelques bugs juste avant de déployer nos releases, nous préférons donc nous en rendre compte au plus tôt.

Les steps

Bitrise nous met à disposition des steps (plus d'une centaine) qui nous permettent de créer des workflows.

slide19-steps

Il faut imaginer ces steps comme des briques de lego. Nous retrouvons des steps pour récupérer le code source, le compiler, le déployer, notifier etc. Ensuite nous construisons par simple assemblage la suite logique nous amenant à déposer un build sur notre store interne.

Les steps sont open source, et si une step n'existe pas... do it yourself (par exemple en utilisant une step de type shell-script)!

La recette

slide20-recette

Evidemment, une chaine d’intégration continue n’en serait pas totalement une sans tests automatisés. Aujourd’hui, dès qu’un dev fait un pull request (PR), la plateforme commence par exécuter les tests unitaires selon les outils propres à chaque environnement, iOS ou Android.

En cas d’échec, le build ne sera pas produit et le développeur est notifié sur Slack. Si les tests sont tous OK, un nouveau build est disponible sur beta, notre store interne. Il peut donc être validé manuellement dans la foulée ou utilisé à toute autre fin par toutes les personnes de l’équipe, ou pas.

Mais à ce stade, seuls les tests unitaires ont été appliqués, nous ne garantissons pas encore la pleine qualité de l'application.

C’est pourquoi, dans un second temps, chaque nuit un workflow vient exécuter une centaine de scénarios fonctionnels sur la base du dernier build produit dans la journée. C’est ce build dont la qualité sera garantie. Chaque scénario est l’occasion de dérouler une série de tests sur les fonctionnalités critiques de l’application, critiques pour notre business, ou critique pour nos utilisateurs.

Au final un rapport est transmis à l’équipe recette toutes les nuits. Elle s’occupera de remonter les éventuelles anomalies dans notre outil de bug reporting (JIRA) après une analyse fine des données du rapport.

Le monitoring

slide21-monitoring

De la même façon que la recette à besoin de mesurer l'activité de test, de mon coté je souhaite mesurer l'activité de la plateforme de delivery applicatif.

Nous avons mis en place une remontée d'indicateurs dans l'ensemble de nos workflows. Ces indicateurs sont injectés à chaque tentative de build directement dans une base de donnée elastic search.

L'interprêtation de ces données se fait au travers de tableaux de bords réalisés avec Kibana.

Ce monitoring nous permet de répondre à deux besoins

  1. Un premier besoin d'analyse temps réel pour détecter rapidement une anomalie. Si par exemple le taux de build en échec explose.

  2. Et un second qui s'inscrit plus dans la durée nous permettant de prendre des décision si on observe la dégradation d'un indicateur. Par exemple si le temps de compilation se dégrade au fur et à mesure des semaines nous allons essayer de comprendre pourquoi et prendre la décision d'engager tel ou tel chantier pour améliorer ce temps de compilation.

Le déploiement en production

slide22-oneclic

Petite spécificité chez nous, j'ai indiqué que les builds de développement se faisaient en flux constant depuis le cloud vers notre store interne (Beta de Crashlythics). Le build de production quand à lui est réalisé chez PagesJaunes.

C'est un choix, celui de ne pas faire transiter des informations sensibles sur le réseau internet. Certainement dans une structure plus petite et avec moins de contraintes nous aurions tout réalisé sur le cloud.

Pour réaliser ce build de production nous disposons d'une plateforme interne, toujours basée sur bitrise. En effet la solution peut être utilisée en ligne de commande (CLI) et dans les mêmes conditions que le cloud. La plateforme va attendre qu'un tag de release soit déployé sur git et lancera automatiquement le build de production avec les configurations de production hébergées en interne.

Quelques chiffres

30 JOURS

C'est le temps qui nous a fallu pour :

  • Monter en compétence sur la plateforme bitrise
  • Réaliser une migration de nos projets de gitlab vers github
  • Monter l'ensemble des workflows, et les tester
  • Synchroniser les équipes

Avec le soucis de ne pas impacter la release en cours !

Nous avons procédé en 2 temps... Migration iOS. Synchronisation des développeurs. On s'assure que tout est opérationnel, les KPI fixés sont bons, les processus autour de la plateforme compris de toutes et tous. Observation. Décision. On y va !

Le projet Android à suivi en quelques jours.

11570 BUILDS

appdays_builds_2

Le avant / après est sans équivoque. Maintenant nous buildons constamment. Du coup nous validons plus rapidement. Un confort de travail pour l'ensemble des équipes opérationnelles.

1500 tests fonctionnels

Toutes les nuits nous éxécutons 1500 tests fonctionnels sur nos deux plateformes iOS et Android. Ils s'agit des tests critiques uniquement.

6 semaines

C'est la durée de nos releases. Nous ne sommes pas arrivé à notre but encore mais cela ne serait tarder. Nous avons une dette de recette à automatiser car l'application a été créée en 2013.

4 profils pour maintenir

slide28-thor

Pour maintenir la plateforme il nous faut ponctuellement des personnes avec de solides connaissances sur les environnements iOS et Android. Quand on parle d'optimiser des temps de compilation, il faut savoir de quoi on parle ! Il faut être intégrateur, ingénieur réseau... Des profils assez complets. Des brutes épaisses.

Pour les sujets sensibles nous faisons intervenir un ingénieur sécurité.

Et enfin pour pouvoir maintenant réduire nos temps de recette, augmenter la qualité de notre application c'est l'automaticien qui risque de prendre une place importante ces prochains mois.

Le mot de la fin

Merci à toutes et tous d'avoir été présent lors de notre présentation aux appdays et surtout d'être venu nous voir pour discuter. En espérant vous croiser de nouveau aux Appdays 2018.