Nous allons voir ensemble comment App Center va nous permettre de gérer efficacement le cycle de vie de nos applications mobiles, de la création à la distribution en passant par la maintenance. App Center dispose d’outils pour nous épauler dans chacune de ces étapes.

Gestion du code source avec Git Flow

Avant de nous lancer dans la création de nos builds il est important d’avoir un système de gestion de code source efficace car cela nous permettra de gérer nos builds plus facilement et surtout de maintenir plus facilement notre application à travers les différentes évolutions par lesquelles elle passera.

Dans notre cas nous utilisons Git et plus précisément un sur-ensemble de commande de Git, Git Flow.

Le principe de Git Flow est très simple il se base sur l’utilisation de 2 branches principales, sur lesquelles aucun « commit » n’est fait directement, uniquement des opérations de « merge ».

· Master : la branche qui est une image du code présent en production. Chaque « commit » de cette branche est un « merge » de notre branche develop et représente donc une mise en production.

· Develop : la branche de développement qui correspond à la branche de travail des développeurs et qui représente le code qui sera poussé dans une version future de notre application. Chaque commit sur cette branche représente l’ajout d’une nouvelle fonctionnalité.

Ensuite viennent les branches de travail à proprement parler, celles sur lesquelles les développeurs vont travailler quotidiennement et sur lesquelles il est permit de « commit » directement, il en existe 3 types :

• Feature : la branche de feature représente comme son nom l’indique une nouvelle fonctionnalité sur laquelle travaille un ou plusieurs développeurs. Elle est toujours « tirée » depuis la branche develop et « mergée » sur celle-ci une fois la feature terminée.

• Release : une branche de release correspond à une nouvelle version de notre application et est « tirée » depuis la branche develop une fois que toutes les features souhaitées ont été « mergées » sur la branche develop. Sur cette branche uniquement des « commits » corrigeant des bugs sont autorisés. Ils correspondent aux retours de recette. Une fois l’application ayant atteint un stade de stabilité convenable pour une mise en production cette branche est « mergée » sur la branche master et sur la branche develop (afin que les corrections apportées soient répercutées pour les prochaines features). A noter qu’un « merge » de cette branche sur la branche master s’accompagne généralement d’un tag git (nommé avec le numéro de version) afin de se repérer facilement sur la branche et pouvoir trouver rapidement le code correspondant à telle ou telle version de production.

• Hotfix : cette branche correspond à un correctif en urgence d’un bug présent dans l’application actuellement en production. Elle est « tirée » directement depuis master et une fois le correctif validé elle est « merge » sur la branche master et sur la branche develop, afin que celle-ci soit toujours à jour.

A noter que ces 3 branches une fois « merge » sont détruites car elles ne sont plus d’aucune utilité, cela permet de garder un arbre git clair et non pollué par d’anciennes branche de feature ou de hotfix. Les seules branches qui ne seront jamais détruites sont les branches master et develop.

Pour mettre en place Git Flow dans notre repository Git rien de plus simple, il suffit de taper « git flow init » une fois Git Flow installé. Ce qui nous permettra d’utiliser les commandes suivantes pour créer et terminer une feature par exemple :

 $ git flow feature start MaSuperFeature
 $ git flow feature finish MaSuperFeature

Il est important de savoir qu’il n’est pas obligatoire d’utiliser Git Flow pour adopter ce système de branche, Git Flow nous permet juste de nous faciliter la vie avec des commandes simplifiées pour créer et terminer les branches.

Maintenant que nos branches sont gérées correctement nous pouvons mettre en place nos builds via App Center et vous allez voir que nos définitions de builds vont se caller parfaitement sur nos branches.

Nous allons mettre en place une build sur la branche develop, définition de build pour la recette des différentes fonctionnalités, cette build peut être déclenchée soit à chaque « commit » (donc dès le « merge » d’une nouvelle fonctionnalité) soit manuellement. Et nous mettrons en place une build sur la branche master qui sera une build pour mettre en production une nouvelle version de notre application.

CI & CD avec App Center

Pour commencer à créer des builds il suffit de connecter notre « repository » à App Center, une fois cela fait les différentes branches de notre « repository » apparaitront dans l’onglet builds. Nous pouvons maintenant créer nos définitions de builds de manière très simple en choisissant le projet à build puis les versions des outils Xamarin à utiliser. App Center nous propose aussi de gérer le versionning de notre application, dans notre cas nous avons opté pour un numéro de builds auto-incrémenté (Build ID). Nous passons ensuite à la partie la plus intéressante les variables d’environnements car elles vont nous permettre de changer la configuration de notre application en fonction de la branche sur laquelle on va être.

Typiquement sur notre branche develop nous allons faire pointer notre application sur une API de recette tandis que sur la build de la branche master nous allons pointer sur l’API de production. Ces variables d’environnements vont donc nous servir à changer cela mais pour se faire il va falloir passer par des scripts.

App Center propose 3 types de scripts de builds (scripts bash) qui sont à placer à coter de notre csproj. Ils sont à nommer « appcenter-[nom_du_script] » :

• Post-Clone : Il est exécuté juste après qu’App Center ait récupéré les sources à compiler. Il peut par exemples servir à télécharger des outils pour les scripts suivants sur la machine de build.
• Pre-Build : Il est exécuté juste avant le build. C’est celui-ci que nous allons utiliser pour modifier le fichier de configuration de notre application. Nous allons le placer à côté du csproj de notre application Android et le nommer appcenter-pre-build.sh pour qu’il soit détecté par App Center.
• Post-Build : Il est exécuté juste après le build. Il peut nous servir à lancer des tests d’UI automatisé par exemple ou à envoyer un build iOS sur Test Flight.

Nous allons utiliser dans notre cas le script de Pre-Build afin de modifier nos valeurs de configuration avant de compiler l’application. Dans notre script nous allons récupérer les variables d’environnement définies dans notre build, pour cela il suffit de les préfixer avec un ‘$’, puis nous allons modifier notre fichier de configuration JSON avec les valeurs de ces variables (nous utilisons jq qui est un outil ligne de commandes permettant de manipuler du JSON).

#!/usr/bin/env bash

# Install jq if needed
if ! brew list jq > /dev/null; then
  brew install jq
fi

tmp=$(mktemp)

# Transform json configuration file
jq --argjson extralogs $SENDEXTRALOGS '.SendExtraLogs = $extralogs' $1 > "$tmp" && mv "$tmp" $1
jq --arg address $BASEADDRESS '.BaseAddress = $address' $1 > "$tmp" && mv "$tmp" $1
jq --arg key $APPCENTERKEY '.AppCenterKey = $key' $1 > "$tmp" && mv "$tmp" $1 

Dans la suite de la configuration de build nous pouvons configurer la signature de notre application (via fichier keystore sur Android ou couple certificat/provisionning profile sur iOS).

On peut également choisir si nous voulons valider l’application compilée par un lancement sur vrai téléphone, si notre application n’arrive pas à se lancer le build sera mis en échec.

Enfin nous pouvons définir la cible de notre build soit nous l’envoyons sur un Groupe de Distribution ou directement sur le store (App Center permet de se lier à un compte Google Play ou Itunes Connect afin de déployer automatiquement notre application). Dans notre cas nous allons distribuer notre application à un groupe de testeurs afin que ceux-ci valident nos features car nous sommes sur la branche develop. Pour créer la build sur notre branche master, il nous suffit de reprendre la même définition sauf que nous changerons nos variables d’environnement par celles de production et nous déploierons notre application sur le store. Il est à noter que nous devons définir nos builds pour chaque OS nous avons travaillé ici sur une build Android mais la marche à suivre est similaire sur iOS. Et voilà ! Nos builds sont prêtes en quelques minutes. Maintenant que notre application est distribuée, passons au monitoring de notre application en production

Surveiller la santé d’une application mobile avec App Center

Une fois notre application déployée en production il est important d’avoir des métriques sur l’utilisation de notre application par les utilisateurs, quelles pages ont été vues, la durée des sessions, etc., afin d’améliorer notre application pour qu’elle soit toujours appréciée par nos utilisateurs.

Il est aussi important de surveiller la santé de l’application avec des métriques sur les erreurs et crashes qui peuvent intervenir durant l’utilisation de notre application, nous ne sommes malheureusement pas des développeurs infaillibles et nous déploieront toujours des bugs en production. Cela est d’autant plus vrai sur le mobile avec des téléphones ayant des caractéristiques très variées et un fractionnement des OS élevé, plus particulièrement sur Android. Il faut cependant être réactif pour corriger ces bugs.

App Center via ses SDKs nous permet d’adresser ces 2 problématiques avec :

• App Center Analytics : Permet d’envoyer des évènements customisés dans App Center que ce soit pour la visite d’une page ou l’interaction sur un bouton. Ce SDK envoie aussi de manière automatique des informations sur la durée des sessions, les téléphones utilisés, les versions d’OS, etc. Toutes les données récoltées et envoyées seront disponibles sur le portail Analytics d’App Center et peuvent être exporté dans Azure Application Insights afin d’analyser ces données de manière plus poussée et d’avoir des possibilités de visualisation plus étendues

• App Center Crashes : Permet d’envoyer automatiquement les informations de crashes dans AppCenter. Pour chaque crashes nous aurons la stack trace associée ainsi que des informations sur les différents téléphones sur lesquels ce crash est intervenu comme la version d’OS, le type de téléphone, etc. Ces informations apparaitront dans la partie Diagnostics d’AppCenter sous la rubrique Crashes.

Nous avons aussi la possibilité d’envoyer des informations sur les exceptions catchées dans notre application, elles apparaîtront dans la sous-rubrique Errors du portail Diagnostics. 

Pour mettre en place ces 2 SDKs rien de plus simple il faut dans un premier temps récupérer sa clé d’API App Center qui se trouve sur la page Overview puis sur iOS d’ajouter dans notre AppDelegate la ligne suivant en spécifiant les SDKs à initialiser ici Analytics et Crashes :

    [Register("AppDelegate")]
    public class AppDelegate : UIApplicationDelegate
    {
        public override bool FinishedLaunching(UIApplication application, NSDictionary launchOptions)
        {
            AppCenter.Start("Ma clé AppCenter", typeof(Crashes), typeof(Analytics));

            return true;
        }
     }

Sur Android la marche à suivre est similaire il faut ajouter la même ligne dans notre activité principale :

    [Activity(Label = "@string/app_name", Theme = "@style/SplashTheme", MainLauncher = true)]
    public class SplashActivity : AppCompatActivity
    {
        protected override void OnCreate(Bundle savedInstanceState)
        {
            base.OnCreate(savedInstanceState);

            AppCenter.Start("Ma clé AppCenter", typeof(Crashes), typeof(Analytics));
        }
    }

Une fois nos SDKs mis en place nous pouvons déjà voir des informations sans avoir à rajouter d’autres lignes de code notamment dans la section Overview de la partie Analytics d’App Center. Nous verrons aussi dans l’onglet Diagnostics les crashes remontés automatiquement par le SDK.

Nous allons maintenant enrichir ces informations afin d’avoir une vue plus pertinente de l’utilisation de notre application. Pour cela nous pouvons ajouter des événements personnalisés pour voir les pages visitées par nos utilisateurs. Il nous suffit d’utiliser la méthode TrackEvent du SDK Analytics. L’utilisation est la même que l’on soit sur iOS ou Android et l’on peut aussi appeler cette méthode dans le code partagé (dans un ViewModel typiquement).

    protected override void OnResume()
    {
	base.OnResume();
        Analytics.TrackEvent($"Visited – Menu");
    }

Les évènements ainsi envoyés seront visibles dans la partie Events de l’onglet Analytics.

Il est aussi important de tracer les exceptions catchées car elles doivent faire l’objet d’une analyse plus poussée et éventuellement d’un correctif si leur nombre est trop élevé. Ce n’est pas parce qu’elles ont été catchées qu’elles n’impactent pas l’expérience utilisateur, certes elles ne correspondent pas à un crash en bonne et due forme de notre application mais elles peuvent être frustrantes pour l’utilisateur.

Pour ce faire il est plus simple de se créer une classe qui remontera nos erreurs catchées afin de ne pas répéter du code partout dans notre application. Dans l’idéal son comportement est défini dans une interface afin de pouvoir être injecter dans un conteneur IoC.

   public class MyErrorHandler : IErrorHandler
   {
      public void Handle(Exception ex) => Crashes.TrackError(ex);
   }

A travers les différentes possibilités d’App Center nous avons vu que pour gérer correctement le cycle de vie de notre application il faut en premier lieux un système de gestion de branches clair et rigoureux, avec dans l’idéal une mise en place de revues de code régulières. Une fois ce système de gestion de branches mis en place on peut s’appuyer sur App Center pour mettre en place une intégration continu et un déploiement continu de notre application. Mais cela ne s’arrête pas là car il nous faut un certain nombre de métriques pour assurer la qualité de notre produit à travers les différentes évolutions qu’il subira au cour du temps (nouvelles feature, nouvelles version d’OS, etc.). Pour cela App Center nous fournis via les SDK Analytics et Crashes tout ce qu’il nous faut pour implémenter cela de manière rapide avec très peu de code à produire.