Continuous Delivery cohérent pour iOS - Voici comment nous avons simplifié le processus

Depuis que j'ai commencé à développer des applications iOS de manière professionnelle en 2015, l'outillage de nos projets a considérablement évolué. À l'époque, en tant que développeur junior, on m'avait confié la tâche chronophage de télécharger les projets dans les App Stores une fois qu'ils étaient terminés. Ceux qui ont de l'expérience en la matière peuvent s'imaginer que cette tâche est rapidement devenue assez fastidieuse avec le nombre croissant de projets. J'ai donc commencé à chercher une meilleure solution.

Au fil des années, nous sommes passés d'une création et d'une exportation manuelles à un déploiement entièrement automatisé de nos projets. Dans ce blog, je vais retracer l'histoire du développement de la livraison continue chez Apps with love. Je vais explorer les différents outils dans l'ordre dans lequel nous avons commencé à les utiliser. Chaque technique s'appuie sur la précédente et apporte de nouveaux avantages, de sorte que le développement se déroule de manière transparente et que la configuration a pu être améliorée progressivement au fil du temps.

Ceux qui ne savent pas encore ce que sont l'intégration continue et la livraison continue - en abrégé CI/CD - et pourquoi ils devraient les utiliser, devraient se renseigner dès que possible ! Une bonne mise en place permet d'économiser énormément de temps et de frustration.

En guise de bref aperçu, nous pouvons diviser nos progrès au fil des ans en trois parties :

• Simplifier les builds

• Automatiser les builds et les tests

• Standardisation à travers tous les projets

Commençons par la première partie : la simplification des builds. Notre outil de choix pour cela est Fastlane. Peut-être l'outil de script de construction le plus répandu pour iOS, il a épargné aux développeurs de l'écosystème Apple des milliers d'heures et quelques maux de tête. Avec Fastlane, tu peux créer des "lanes", c'est-à-dire une série d'instructions à exécuter. De nombreuses actions sont disponibles et peuvent être utilisées pour tester, créer et télécharger tes projets.

Construire avec Fastlane

Nous avons commencé à utiliser Fastlane en 2015. Il nous a permis de simplifier l'exportation des fichiers .ipa de nos projets Xcode. Nous avons mis en place un "gymfile" dans chaque projet. Cela permet d'indiquer à Fastlane quel schéma doit être utilisé, comment il doit être exporté et quelles autres configurations sont éventuellement nécessaires. L'utilisation de ˋgymˋ signifiait que nous n'avions plus besoin de passer par Xcode pour exporter des builds. Au lieu de cela, nous pouvions le faire à partir du terminal, ce qui nous faisait souvent gagner quelques minutes et était moins sujet aux erreurs, puisque les exigences étaient déjà définies dans le gymfile.

Code Signing avec Match

Les développeurs iOS se souviennent certainement tous du moment où ils ont fini de développer leur toute première application. Puis vient la partie de la publication et la lutte avec le Code Signing commence. C'est souvent assez énervant, surtout lorsqu'il faut créer manuellement des certificats et des profils sur le portail Apple Developer. Si l'on multiplie cet effort par des équipes App Store très différentes et des dizaines de projets, cela devient vite un travail énorme pour garder une vue d'ensemble.

Nous avons commencé à automatiser la génération des Code Signing Assets avec ˋfastlane sighˋ. Ainsi, les signing assets nécessaires sont générés, téléchargés et installés sur lʼordinateur du développeur avant que lʼapplication ne soit construite. De la même manière, Xcode a commencé à supporter l'Automated Provisioning il y a quelques années. Les deux ont cependant un gros inconvénient : la collaboration en équipe n'est pas vraiment soutenue.

L'une des principales raisons pour lesquelles nous n'avions auparavant qu'une seule personne responsable de la création et du déploiement de nos projets était le fait que le partage des certificats et des profils de déploiement sur différents ordinateurs posait un gros problème.

Pendant un certain temps, nous avons stocké nos profils et nos certificats dans le Drive sur notre Google Workspace. Mais lorsqu'un développeur oubliait de les télécharger ou ne les trouvait tout simplement pas, la personne se contentait souvent de créer un nouveau certificat et un nouveau profil. Cela interrompait au mieux les processus de travail des autres développeurs et au pire les builds livrés aux clients. En outre, cette "solution" est bien sûr loin d'être optimale du point de vue de la sécurité, mais bon, c'est comme ça qu'on faisait à l'époque.

Le salut est venu sous la forme d'un nouvel outil Fastlane appelé "Match". Il prend les signing assets (certificats et profils) et les synchronise via un dépôt Git crypté. Nous avons commencé à intégrer Match dans tous nos projets et jusqu'à présent, il s'avère être un énorme gain de temps et un élément fondamental de notre système de CI.

Nous utilisons un seul repo pour Match, avec une branche séparée pour chaque équipe App Store. Nous utilisons un seul repo parce que nous n'avons pas besoin que les différentes équipes aient accès à certaines sections. Mais si le scénario l'exige, Match fonctionne également avec différents repos ou même des buckets S3.

Builds pour plusieurs environnements

Dans pratiquement tous les projets professionnels, tu es confronté à la nécessité de créer différentes versions de tes builds. Peut-être que tu as différents environnements de staging et de production ou des indicateurs de fonctionnalités de débogage pour les builds des développeurs. Ou peut-être que tu veux livrer des builds de la branche Dev aux développeurs ou à l'assurance qualité, mais aussi des builds de la branche Main à tes clients.

Face à ce défi, nous avons dû repenser le stockage de nos configurations de build dans Gymfile, Matchfile et ainsi de suite. Nous avons donc rapidement déplacé toutes nos configurations dans des fichiers .env et modifié les autres fichiers pour qu'ils soient simplement lus à partir de l'environnement. Créer le bon build n'est désormais plus qu'une question de spécifier le bon environnement :

Déploiement avec Updraft

De nombreuses équipes utilisent TestFlight pour distribuer les builds de pré-production et, pour certains scénarios de test (le PAI en est un), c'est la seule option fiable. Cependant, pour la plupart de nos projets, nous préférons partager les builds avec notre propre outil Updraft, qui permet une distribution facile par e-mail, Slack et MS Teams, sans avoir à enregistrer les appareils de test au préalable. Et comme nous utilisons Updraft en permanence, nous avons développé notre propre action Fastlane, qui récupère le fichier .ipa exporté avec ˋgymˋ et le transmet immédiatement aux testeurs via Updraft. Tu peux essayer Updraft à l'adresse getupdraft.com - il est gratuit et fonctionne également pour les projets Android.

Autres conseils et astuces

Nous avons également expérimenté autour d'autres actions Fastlane afin d'améliorer nos processus. Voici quelques-unes des choses que nous faisons avec Fastlane :

• Linting avec Swiftlint

• Exécution de tests et collecte de rapports de couverture

• Mise à jour de Cocoapods avant le build

• Téléchargement de fichiers DSYM vers Firebase Crashlytics

• Incrémentation du numéro de build

• Enregistrement de nouveaux appareils de test

Comme vous pouvez le constater, Fastlane est incroyablement polyvalent et devrait être à la portée de tous les développeurs iOS.

L'histoire continue...

Il y a bien sûr encore beaucoup d'autres choses à dire sur la livraison continue. Par exemple, comment nous obtenons un feedback plus rapide et comment nous nous assurons que nos testeurs et nos clients ont toujours accès aux builds les plus récents, tout en soulageant nos développeurs d'une étape manuelle supplémentaire au profit de l'automatisation. Nous en parlerons plus en détail une autre fois. En attendant : merci de votre lecture, j'espère qu'elle a été intéressante. Et si vous avez des questions ou des suggestions, je suis à votre disposition !

Bonus

Nous sommes heureux de partager ici une configuration Fastlane complète. Nous espérons que cela vous donnera un aperçu de la manière dont tout s'assemble : Cliquez ici pour accéder à Github.