Dans le développement informatique, on finit toujours par ressentir le besoin d’automatiser certaines tâches et ce pour plusieurs raisons :
- Ce qui est répété peut-être automatisé
- Cela évite des erreurs
- Cela fait gagner du temps
- C’est plus rapide
En effet, un processus automatisé ira bien plus vite que le développeur et pour cause, pendant que la machine réalisera la tâche automatiquement, le développeur pourra faire autre chose comme écrire cet article ou bien le lire…
Avant de commencer quoi que ce soit. Il faut savoir que cet article n'abordera PAS les pipelines azure avec YAML. Par conséquent, je conseille de désactiver cette feature pour la suite.
Présente en haut à droite, cliquez sur « Preview Features » pour trouver un autre menu, désactivez celle qui contient le mot « YAML » pour passer à la suite.
Cela permettra ainsi d’être sur l’ancien mode d’édition de pipeline. Dans le futur, j’expliquerai comment faire avec l’autre méthode.
Azure Pipeline
Sur cet article, c’est ce sujet qui nous intéresse. On y retrouve ainsi plusieurs onglets. Et nous choisirons « Builds ».
Sur le nouvel écran, créons un nouveau pipeline.
La localisation du code est une constante importante. J’enregistre généralement mon code dans Azure DevOps dans l’onglet « Repos ». Mon projet exemple ici est « Horizon ». Choisissez Xamarin.iOS, ce choix contient par défaut suffisamment de chose pour travailler.
Ensuite supprimez les tâches désactivées sauf celles qui concernent Apple et activez ces dernières pour arriver à ce résultat.
Etape 1 : Apple
Pour la suite des étapes vous aurez besoin d’un fichier .p12 et .provisioningProfile. La méthode d’obtention de ces fichiers est largement documentée sur internet, voici d’ailleurs quelques liens du site web « pandasuite ».
Fichier P12 :
App Id :
ProvisioningProfile :
Une fois en possession du fichier .p12, placez le dans la tâche « Install an Apple certificate ».
Notez que le certificat requiert un mot de passe pour être ouvert par votre machine de build. En haut, cliquez sur « Variables » pour remplir celle nommée « P12password ».
Pour la partie « Install an Apple provisining profile » faites de même en y plaçant le fichier.
Dans la section « Build Xamarin.iOS », il peut être utile de préciser quel fichier .sln est à compiler dans le cas de solutions qui disposent de plusieurs fichiers.
On désactivera également « Build for iOS Simulator”.
Étape 2 : Android
Appuyez sur "+" pour ajouter une nouvelle tâche et utilisez la recherche pour ajouter la tâche « Xamarin.Android ». Puis sélectionnez le fichier .csproj associé dans ses paramètres.
Étape 3 : Numéro de version
Lors du déploiement de vos applications, avoir des numéros de version qui évoluent au fur et à mesure de l’avancement de vos projets. La norme est d’utiliser la manière suivante :
[Major].[Minor].[Fix]
Généralement la « Major » et la « Minor » évoluent de manière épisodique. Elles sont mises à jour à la main. Le « Fix » en revanche évolue constamment, on peut donc laisser l’usine mettre à jour elle-même ce numéro.
Pour faire les choses sans trop se compliquer la tâche, on peut utiliser une extension gratuite à ajouter dans nos tâches. Celle de James Montemagno peut être téléchargée ici :
Cela permet d’ajouter et d’utiliser les tâches suivantes :
Elles permettent d’agir en tant que facilitateur. Pour iOS, il convient de remplir les champs de « Bump iOS Version » comme ceci :
Il n’y pas de grandes difficultés ici, il faut aller rechercher le fichier info.plist qui se trouve dans le projet iOS.
Ensuite la variable « $(Build.BuildNumber) » se trouve dans l’onglet « Options » en haut. Cela correspond au champ « Build number format ». Par défaut la valeur est la suivante : « 1.1$(rev:.r) » que j’ai tendance à modifier par « 1.1.0-$(Build.BuildId) » qui correspond au numéro de Build généré par l’usine et non au numéro de la version générée par le pipeline.
Enfin la section « Version Name (CFBundleShortVersionString) » correspond au numéro de version qui est affiché aux utilisateurs. Un « -Dev » peut être une bonne indication lors du téléchargement de vos packages depuis une plateforme tel que « AppCenter ».
Étape 4 : Ajouter un commentaire au build
En raison de l'automatisation de nos compilations et versions de développement, il est possible que les futurs utilisateurs de la version souhaitent connaître les raisons qui ont pu provoquer cette nouvelle version.
Par défaut, dans mes développements, je fais en sorte de mettre le commentaire de commit en tant que raison de déploiement. Pour ça, on va rechercher la tâche « Bash ».
Ensuite, dans la tâche, j’écris le script qui permet de créer un fichier et d’y placer le commentaire.
J’ajoute également « $(system.defaultworkingdirectory) » dans le Working Directory de la section “Advanced”, afin que le script puisse s’exécuter au bon endroit.
Étape 5 : Publier l’artefact
Deux tâches sont déjà implémentées par Azure DevOps : « CopyFilesTo » et « Publish Artifact : drop ».
Assurez-vous que la première comporte les éléments suivants :
Étape 6 : Intégration continue
Dernière étape et sûrement l’une des plus intéressante. La partie d’intégration continue se situant dans l’onglet « Triggers ».
Ainsi, en activant ce critère, l’usine lancera automatiquement les builds lorsque des commits auront lieu sur la branche « master ». Cela évitera que celle-ci se déclenche sur les branches de type « features ».
Avec cette fonctionnalité, il est également possible de déclencher des builds à partir des fins de build d’autres pipelines.
Étape 7 : (Bonus) Avoir une usine parlante
Si votre usine de développement se trouve dans la pièce où vous développez, il peut être intéressant et innovant de faire parler l’usine pour connaître l’état d’avancement, savoir si un échec a lieu ou bien si une build démarre.
Pour cela, il faut ajouter une tâche « Bash » et simplement coller le texte suivant à l’intérieur :
say "Bilde de $(Build.DefinitionName) en cours par $(Build.RequestedFor)"
Ainsi « say » est la commande utilisée par Siri sur mac pour parler. Le fait d’écrire « Bilde » est une suggestion à cause de son accent en français. « DefinitionName » est le nom du pipeline en cours et « RequestedFor » le nom de la personne qui a fait un commit, une pull request ou le lancement du pipeline en mode manuel.
Maintenant c'est à votre tour.
