Une fois la partie développement et build d’une application réalisée. Le but suivant est sa distribution. Selon les besoins, une application sera déployée pour un nombre plus ou moins restreint d’utilisateurs. On retrouvera généralement les modèles suivants :
- AppStore/PlayStore (BtoC) Tous les utilisateurs
- AppStore/PlayStore Beta (BtoC) Nombre restreint d’utilisateurs
- InHouse (AirWatch, AppCenter, …) Nombre restreint d’utilisateurs (entreprise)
- AdHoc (AppCenter, …) Nombre très restreint d’utilisateurs (connus et choisis)
AppCenter
Produit de Microsoft destiné à remplacer HockeyApp. AppCenter se veut plus simple à prendre en main et s’accompagne de nombreuses features supplémentaires.
Pour commencer, il faut disposer d’un compte Microsoft, s’inscrire au service et créer ou rejoindre une organisation.
Les applications sont ensuite affiliées à une organisation. Sachez d’ailleurs que le propriétaire d’une organisation peut changer.
Pour mon projet « Horizon », je vais créer l’organisation « Peggy18 », le nom de l’équipe à laquelle j’appartiens lors de hackathons. Horizon est développé pour iOS et Android, je vais donc créer deux applications sur cette organisation sur le site AppCenter.
Le choix de la plateforme n’est pas anodin. AppCenter n’agit pas simplement comme un MDM. Il s’agit là d’une véritable plateforme pour compiler et déployer des projets. Bien sûr, si App Center est gratuit, le service de compilation utilise les machines de Microsoft qui lui est payant. Je conseille de voir l'article sur les builds avant.
Le déploiement d’application est pareil pour iOS et Android donc la suite sera identique.
La partie « Groups » de « Distribute » nous intéresse plus. Par ici, on peut déployer des applications pour différents groupes. Ainsi chaque groupe peut disposer de sa propre version. Le testeur peut disposer de la version « dev » ou « master », la version « demo » serait mise à disposition à chaque fin de sprint après la présentation, etc.
Appuyez sur « Add Group », au centre de l’écran.
En cochant « Allow public access », vous pouvez faire en sorte d’avoir un lien pour permettre à n’importe qui de télécharger l’application sans avoir à se connecter. Cependant cette option n’est véritablement utile que dans le cadre d’un déploiement « InHouse » puisque dans un cadre « AdHoc » pour iOS, les devices doivent être enregistrés.
Une fois le groupe sauvegardé, en retournant dans les paramètres, on retrouve alors, une option supplémentaire : celle de pouvoir ajouter automatiquement de nouveaux devices. Malheureusement cette option est incompatible avec le lien public, mais il permettra d’ajouter de nouveaux utilisateurs sans devoir signer encore l’application dans l'usine de build.
Azure DevOps
De retour dans Azure DevOps, dans la section « Pipelines/Release », on rajoute une nouvelle release.
En le renommant et en créant une tâche vide, on obtient globalement ce résultat.
Nous allons commencer par attacher l’artifact de notre pipeline de build.
En appuyant ensuite sur l’éclair de la section « Artifacts », on peut alors permettre à notre pipeline de faire du déploiement continu. En incluant la branche spécifique à notre besoin. Ici, « demo », celle-ci se déclenchera après la validation de chaque commit sur elle.
En allant sur la partie « Stages », sur le job « Deploy iOS », nous allons ajouter des tâches nécessaires au déploiement. Une seule nous intéresse :
Il va ensuite falloir remplir quelques données sur la tâche, ce qui va demander de faire quelques allers retours entre AppCenter et AzureDevOps.
En allant sur AppCenter, rendez-vous dans les paramètres du compte, puis dans API Tokens pour générer un token en « Full Access ».
De retour dans Azure DevOps, on ajoute le service de connexion AppCenter.
Ensuite le « App slug » représente le nom de l’organisation et de l’application au sein de « AppCenter » séparé pas un « / ». En cas de doute, ils correspondent à ceci dans l’URL :
Cela donne donc « Peggy18/Horizon-iOS » sur ce projet.
Pour la partie « Binary file path », il faut simplement aller chercher le binaire qui nous intéresse .app ou .apk selon l’application. Attention, le binaire n’est visible que si la build qui a généré l’artifact l’a bien publié.
En dessous les « Release notes », plusieurs possibilités s’offrent à nous. Soit écrire un texte lambda pouvant convenir à toutes les situations soit récupérer le fichier .txt généré par notre build (cf : article dédié au pipeline de build). Dans ce dernier cas, il apparaitra au même titre que le binaire dans la sélection de fichier.
Enfin le « destination IDs » correspond à l’iD de votre groupe dans AppCenter. Il est visible dans les paramètres de ce dernier. Si vous n’en mettez pas, le groupe par défaut sera utilisé.
Cela donne le résultat suivant :
Et le job est terminé. Il est possible de rajouter des tâches (vocales par exemple, pour notifier les développeurs proches de l’usine que la version est disponible.
