Cet article détaille les récents projets open source Buck et xctool, les outils d'industrialisation utilisés par Facebook en interne pour leurs applications natives sous Android et iOS.
Buck
FacebooK a récemment mis en open source le projet Buck, leur outil interne d'industrialisation de leurs applications Android natives. Inspiré de Google Blaze, Buck a été créé pour gérer la complexité associée aux multiples bibliothèques Android et pour réduire le temps d'assemblage. Après avoir lancé Buck, les 4 applications Android natives développées par Facebook ont arrêté d'utiliser la même arborescence de code et le même outil d'assemblage, rendant ainsi le développement plus simple, plus fluide et avec moins d'erreurs. Les 38 bibliothèques initiales se sont transformées en 500 modules partagés entre les 4 applications. Le temps d'assemblage est passé de 3m 40s à 1m 30s lors du premier passage sur l'arborescence de code, Buck remplace désormais le système initial basé sur Ant.
Buck est écrit en Java avec des règles de compilation initialement codées en Python, puis en Jython pour une évaluation plus rapide. L'outil est pour l'instant utilisé pour compiler du code Java Android, mais l'équipe travaille pour permettre la compilation de pur code Java, non lié à Android et pourrait être étendu pour compiler des projets Python voire d'autres.
Le code Android de Facebook est organisé en une arborescence composée de sous arborescences indépendantes formant un graphe orienté acyclique permettant une exécution des règles d'assemblage en parallèle associées aux différentes sous arborescences, le tout en un temps plus court. Les fichiers d'assemblage, contenant les règles, sont répartis dans l'arborescence de code, un pour chaque module Android existant. Un fichier d'assemblage est executé seulement si il y a une modification d'un fichier au niveau du module. Ces assemblages peuvent être executés en parallèle. Activer le parallélisme sur 8 threads réduit le temps d'exécution des tests unitaires de 20 à 4mn, selon Michael Bolin, le créateur de Buck. Il a détaillé le système d'assemblage durant sa session à DevCon New York 2013.
Buck sait gérer plusieurs version d'un même fichier comme l'explique Bolin dans un post sur Google+ :
Un autre problème compliqué dans l'assemblage d'applications Android est la génération du fichier R.java. Sans rentrer dans les détails, vous pouvez assembler plusieurs applications Android qui dépendent de la même classe R. Pour une classe Java ordinaire, vous compileriez la classe une première fois et les autres classes en dépendraient. A l'inverse, avec Android, la version de R dont vous avez besoin pour compiler dépend de l'application Android dans laquelle l'ensemble du code Java final a été compilé. Il est inutile de compiler différentes version de votre code Java pour toutes vos applications Android que vous assemblez, du coup Buck utilise un moyen astucieux (créer un R.java différent pour chaque compilation plutôt que pour chaque exécution) pour réduire la duplication à la compilation.
Bientôt l'équipe à l'intention d'ajouter un demon pour surveiller l'édition de fichier, permettant d'exécuter l'assemblage dès qu'il détecte une modification.
Buck tourne sur MacOS et Linux et l'équipe a prévu le support sur Windows. Shawn Pearce, le créateur de Gerrit, propose d'utiliser Buck plutôt que Maven, mettant en avant la vitesse et d'autres raisons :
buck: clean: 0.452s, full 1m21.083s [*], no-op: 7.145s,
maven: clean: 4.596s, full 2m53.776s, no-op: 59.108s,
[*] assemblage complet incluant la récupération des dépendances ; le temps peut varier suivant les performances des serveurs distants.
Pearce a aussi remarqué des inconvénients avec Buck :
- pas supporté sur Windows
- pas de support natif de Maven Central (ajouté via des macros)
- pas de support natif de GWT, Prolog ou WAR (ajouté via des macros)
- le lancement de Buck nécessite Ant
xctool
xctool est aussi un outil d'assemblage récemment mis en open source par Facebook, utilisé pour assembler des application iOS. xctool remplace xcodebuild avec les fonctionnalités suivantes :
- peut exécuter les mêmes tests que Xcode.app
- la sortie des assemblages et des résultats de test sont capturés en JSON, sans nécessiter de traitement en sortie
- xctool affiche des messages uniquement lorsqu'il rencontre une erreur et non pour chaque fichier source comme avec xcodebuild
Nous voulions savoir pourquoi Facebook a développé un nouvel outil sur la base de xcodebuild et nous avons rencontré Fred Potter, committer sur xctool, pour lui demander en quoi cet outil est plus intéressant :
Un des avantages de xctool est la possibilité de lancer les tests unitaires en ligne de commande de la même manière que Xcode.app via l'interface graphique. Ceci est indispensable pour mettre en place un système d'intégration continue pour iOS. Vous devez pouvoir exécuter les mêmes test en automatique que ceux qui sont réalisés par les dévelopeurs en local sur leurs machines et xcodebuild n'exécute pas les tests de la même façon que Xcode.app. Avec Xcode 4, Apple a réellement intégré les tests unitaires dans Xcode - il y a un nouvelle action "Test" à coté de "Build" et "Run" ; Dans le navigateur Xcode vous pouvez sélectionner lesquels de vos tests unitaires vous voulez activer ou désactiver ; et si vous avez des tests dépendants du simulateur iOS (i.e. tests applicatifs), Xcode lance automatiquement le simulateur et exécute vos tests. C'est une nette amélioration mais il semble qu'Apple ne l'ai pas répercuté dans xcodebuild ce qui rend l'automatisation de l'assemblage et des tests bien plus difficile.
Un autre problème important est le rapport d'erreurs d'assemblage et de test. Avec xcodebuild vous récupérez un flux gigantesque de texte contenant les commandes de compilation, les erreurs de compilation, les alertes et des sorties de test issues de OCUnit. Si vous voulez déterminer de manière automatique quel composant ou quel test unitaire a échoué, vous devez écrire une expression régulière conséquente pour traiter ces données et c'est ce que nous avons fait avec la communauté iOS. Ca peut marcher mais c'est un peu lourd. Avec xctool nous avons modifié xcodebuil et OCUnit en générant les résultats de l'assemblage et des tests sous forme d'un flux JSON structuré. Ce qui facilite le rendu de l'assemblage et des tests dans n'importe quel format. Par exemple nous avons développé un rendu affichant les résultats avec des couleurs adaptées (https://fpotter_public.s3.amazonaws.com/xctool-uicatalog.gif). D'autres l'ont utilisé pour générer un XML JUnit permettant l'affichage dans Jenkins.
Nous avons principalement développé xctool pour notre système d'intégration continue, mais beaucoup de dévelopeurs l'utilisent localement sur leur machine. C'est pratique si vous avez besoin d'un outil en ligne de commande pour exécuter vos tests.
