TestFlight, HockeyApp et le déploiement continu

Nous vous parlions de la qualité et l’industrialisation des développements mobiles sur iOS & Android dans un précédent article et, à cette occasion, nous avions évoqué TestFlight comme solution permettant la gestion de vos builds mobiles et leur diffusion auprès de vos testeurs. Dans cet article, nous allons revenir sur cet outil afin de proposer et d’approfondir certaines astuces d’utilisation. Nous nous efforcerons également de le comparer à d’autres solutions du marché, notamment HockeyApp. Au programme :

• Gestion des builds, des utilisateurs et des permissions
• Le SDK Testflight : Logs à distance, checkpoints
• Testflight & iOS : Optimiser la gestion de ses builds avec les Targets
• Les alternatives à Testflight

[Update : 20/02/2014]

Suite probablement à son achat par Apple (http://mashable.com/2014/02/21/apple-burstly/), avec un billet sur son blog (http://help.testflightapp.com/customer/portal/articles/1450414) TestFlight a récemment annoncé qu’Android ne sera plus supporté à partir du 21 mars 2014.

Introduction

TestFlight est une plateforme qualifiée de Mobile Application Manager (MAM), permettant notamment :

• le déploiement des build iOS et Android sur des terminaux mobiles
• le suivi des usages et des sessions utilisateurs
• la récolte des rapports de crash

Afin de mettre en place une plate-forme de livraison continue, TestFlight peut être facilement intégré dans Jenkins. Cela permet de fournir aux clients et testeurs la toute dernière version disponible d’une application et de simplifier le processus de communication pour ainsi pouvoir bénéficier de retours immédiats concernant le livrable.

Utilisateurs et applications

Vous pouvez accéder aux fonctionnalités de TestFlight depuis les deux sections principales : Apps et People. Apps est le portail permettant l’upload / modification / suppression des builds et le suivi des bugs et de l’utilisation de l’application. La page People donne accès à la gestion des utilisateurs de l’équipe, et fournit des interfaces pour la soumission des invitations ainsi que la révocation de l’accès à une application ou à un build spécifique.

Les utilisateurs de la plateforme peuvent être classés en équipes, c’est à dire un groupe d’individus ayant accès au même ensemble d’applications. Chaque utilisateur peut faire partie d’une ou plusieurs équipes.

Les utilisateurs peuvent avoir deux rôles : normal (testeur bêta) et developer. L’utilisateur developer peut soumettre des nouvelles builds et accéder aux rapports et détails des crashs.

Pour chaque application créée, le développeur peut soumettre autant de builds successifs que nécessaire, chacun avec une taille limitée à 800 Mo.

Chaque version de l’application est indiquée dans la page Build, suivie par son numéro de build.

À côté de chaque icône, un numéro est affiché indiquant la version (sous iOS, CFBundleShortVersionString) et, entre parenthèses, le numéro de build (CFBundleVersion).

Détails de l’application

En sélectionnant App Information les principaux détails du build sont affichés. Ceux-ci contiennent le Bundle ID, la version du SDK TestFlight, les dates de création et de soumission. La page d’information sur l’application fournit également un lien permettant au développeur de supprimer l’application sélectionnée ainsi que toutes ses données relatives.

La page App Token contient la valeur de cette variable qui est utilisée lors de l’intégration du SDK dans l’application.

Détails du build

Une fois que vous avez choisi un build spécifique parmi ceux ajoutés, une liste d’activités s’affiche, contenant les événements les plus importants dans le cycle de vie de cette version. Les Events, qui sont actualisés en temps réel, peuvent concerner des invitations d’utilisateurs, les permissions et les installations.

À partir de la page de build, en cliquant sur le lien Permissions, il est possible d’autoriser et / ou supprimer l’accès aux utilisateurs et manuellement informer les membres de l’équipe sur la disponibilité de la release. La page offre également la possibilité de vérifier quels terminaux sont utilisés par les testeurs.

Dans le menu de gauche, il est possible d’accéder aux pages Feedback, Session, Crash et Checkpoint. Pour que ces informations soient correctement remontées, le SDK TestFlight doit être installé au sein de votre application mobile.

Le SDK TestFlight

Afin de tirer pleinement parti de TestFlight, un SDK doit être installé dans l’application via une librairie spécifique, disponible pour iOS et Android. Pour l’intégrer sous iOS, téléchargez le package sur le site puis insérez le binaire du SDK et la bibliothèque libz.dlyb parmi les frameworks de l’application.

Une fois que le SDK est installé, le développeur doit fournir l’App Token, qui est l’ID utilisé par TestFlight afin de reconnaître l’application qui génère la session. Ces informations sont disponibles sur la page App Token dans la page de l’application sur le site TestFlight. Si aucun build n’a été créé, le développeur peut sélectionner le lien Add an app et créer un nouveau token pour un Bundle ID donné.

Chaque token peut être uniquement attribué à un Bundle ID et ne peut être utilisé dans d’autres applications.

Une fois l’App Token récupéré, un code spécifique, signalant qu’un utilisateur a commencé une nouvelle session, doit être ajouté dans la méthode application:didFinishLaunchingWithOptions:

[TestFlight takeOff:APP_TOKEN];

Des paramètres supplémentaires peuvent être ajoutés avant le takeOff, par exemple, en appelant la méthode addCustomEnvironmentInformation:forKey:  qui permet de remonter des informations spécifiques à l’application à afficher dans le panneau de la session sur le site Web de TestFlight.

Fonctionnalités avancées (Logs, checkpoints)

TestFlight permet également de rediriger les logs de l’application dans le but de les lire directement en ligne, depuis la console d’administration de TestFlight. Il est également possible de créer des Checkpoints, c’est à dire des mots-clés définis par le développeur et qui permettent de suivre les étapes qui sont effectuées par l’utilisateur final.

Pour ce faire, le développeur doit modifier le fichier precompiled header (.pch) et y ajouter les lignes suivantes :

#import "TestFlight.h"
#define NSLog(__FORMAT__, ...) TFLog((@ "%s [Line %d] " __FORMAT__), __PRETTY_FUNCTION__, __LINE__, ##__VA_ARGS__)

En modifiant le fichier pch, les méthodes TestFlight deviennent disponibles dans chaque classe de l’application.

Le logging à distance est tout simplement activé par l’habituelle fonction NSLog( … ), tandis que les points de contrôle peuvent être validés en appelant la fonction :

[TestFlight passCheckpoint:CHECKPOINT_NAME];

Les Targets et les builds

Dans certaines circonstances, il peut être utile de distribuer plusieurs builds de la même application dans le but de fournir des configurations différentes de la même base de code. À titre d’exemple, cette pratique peut être utile pour activer ou désactiver une fonction spécifique (A/B Testing), ou pour cibler différents environnements de services web. Il est possible, par exemple, de créer une build pointant vers le serveur de production et une autre pointant vers le serveur de test.

Une telle fonctionnalité peut être obtenue en utilisant des targets Xcode. Chaque target aura un bundle ID différent et contiendra un plist différent, ce qui rend le changement de configuration plus facile.

Lors du déploiement via TestFlight, chaque cible est considérée comme une application différente avec son propre cycle de vie et, par conséquent, il faudra créer un token différent par app.

Une autre caractéristique des Targets consiste en une séparation des build settings, permettant des personnalisations de cible en cible. Parmi ces paramètres, l’un des plus utiles est la possibilité d’ajouter des macros préprocesseur spécifiques qui peuvent varier d’une cible à l’autre.

Dans l’exemple ci-dessous, la cible « Prod » contient une macro préprocesseur  « PROD=1 » spécifique. Cette information peut être consultée n’importe où dans le code de l’application en utilisant le compilateur macro defined et, en particulier, pour fournir un AppToken différente selon la cible.

La méthode application:didFinishLaunchingWithOptions: contiendra donc le code suivant :

#if defined(PROD)
    [TestFlight takeOff:APP_TOKEN_PROD];
#else
    [TestFlight takeOff:APP_TOKEN_DEV];
#endif

Alternatives

Il existe plusieurs alternatives à TestFlight, la plus connue étant HockeyApp. HockeyApp permet aux développeurs de soumettre non seulement des applications pour Android et iOS, mais aussi pour Mac OS, Windows et Windows Phone. Tout comme TestFlight, HockeyApp contient un SDK permettant la récolte des crash et feedbacks.

Une autre caractéristique intéressante d’HockeyApp est la capacité de créer des WebHooks, ce qui permet à la plateforme de notifier une URL personnalisée à chaque fois qu’un événement spécifique, par exemple un nouveau crash ou feedback, a eu lieu.

HockeyApp fournit également un ensemble d’API permettant la création et la gestion des membres de l’équipe, invitations, profils d’approvisionnement, crash, feedback, etc.

Enfin, le SDK HockeyApp intègre des fonctions pour authentifier les utilisateurs via un formulaire affichable à l’écran. Cette fonction peut être utilisée pour empêcher les utilisateurs d’accéder à l’application si l’accès a été révoqué.

Contrairement à TestFlight, le modèle de prix de HockeyApp est différent : en dehors d’un essai gratuit de 30 jours, les plans commencent à 100 dollars/an pour 5 applications.

D’autres solutions peuvent impliquer un déploiement sur un serveur privé : c’est le cas des outils comme KnappSack ou Shenzhen, même si leur mise en place peut s’avérer compliquée. Par exemple, la nécessité d’installer un certificat SSL sur le domaine, à partir iOS 7.1 (http://stackoverflow.com/a/20276908 ).