Publier des applications iOS sur l'App Store avec GitLab et fastlane

Comment GitLab avec fastlane collecte, signe et publie des applications iOS sur l'App Store.

Nous avons récemment publié un article sur la façon de créer et d'exécuter rapidement une application Android avec GitLab et fastlane . Ici, nous verrons comment créer et exécuter une application iOS et la publier sur TestFlight. Découvrez à quel point je modifie l'iPad Pro avec l'IDE Web GitLab , prenant la version et obtenant une mise à jour de la version de test de l'application sur le même iPad Pro où je l'ai développé.

Ici, nous prenons une application iOS simple sur Swift avec laquelle j'ai enregistré une vidéo.

Quelques mots sur la configuration de l'Apple Store

Nous aurons besoin d'une application dans l'App Store, de certificats de distribution et d'un profil d'initialisation pour tout lier ensemble.

La chose la plus difficile ici est de configurer les droits de signature dans l'App Store. J'espère que vous pourrez le découvrir par vous-même. Si vous êtes débutant, je vais vous orienter dans la bonne direction, mais ici, nous ne parlerons pas des subtilités de la gestion des certificats Apple, et ils changent constamment. Ce message vous aidera à démarrer.

Mes candidatures

Vous avez besoin d'une application dans l'App Store Connect pour avoir un ID pour la configuration .xcodebuild . Le profil et l'ID d'application combinent l'assemblage du code, le prix et la disponibilité, ainsi que la configuration TestFlight pour distribuer les applications de test aux utilisateurs. Ne faites pas de test public, privé suffit si vous avez un petit groupe, une configuration simple et n'avez pas besoin d'autorisations supplémentaires d'Apple.

Profil d'initialisation

En plus de la configuration de l'application, vous avez besoin des clés de distribution et de développement iOS créées dans la section Certificats, identificateurs et profils de la console Apple Developer. Tous ces certificats peuvent être combinés dans un profil d'initialisation.

Les utilisateurs d'authentification doivent pouvoir créer des certificats, sinon vous verrez une erreur dans les étapes cert et soupir .

Autres options

Outre cette méthode simple, il existe d'autres façons de configurer les certificats et les profils. Donc, si vous travaillez différemment, vous devrez peut-être reconstruire. Plus important encore, vous aurez besoin de la configuration .xcodebuild , qui pointera vers les fichiers nécessaires, et le trousseau devrait être disponible sur l'ordinateur de génération pour l'utilisateur sous le nom duquel fonctionne le runner. Nous utilisons fastlane pour les signatures numériques, et s'il y a des problèmes ou si vous voulez en savoir plus, consultez leur documentation détaillée sur les signatures numériques .

Dans cet exemple, j'utilise l' approche cert et soupir , mais pour une application réelle, la correspondance est probablement meilleure.

Préparation de GitLab et fastlane

Préparation de CI Runner

Après avoir collecté toutes ces données, nous procédons à la configuration du runner GitLab sur le périphérique MacOS. Malheureusement, la création d'applications iOS n'est réelle que sur MacOS. Mais les choses peuvent changer, et si vous attendez des progrès dans ce domaine, gardez un œil sur des projets comme xcbuild et isign , et notre tâche interne gitlab-ce # 57576 .

La configuration d'un coureur est très simple. Suivez les instructions actuelles pour configurer GitLab Runner sur macOS .

Remarque Le coureur doit utiliser l'exécutable shell . Cela est nécessaire pour construire iOS sur macOS afin de travailler directement en tant qu'utilisateur, et non via des conteneurs. Si vous utilisez un shell , l'assemblage et les tests sont effectués au nom de l'utilisateur du runner, directement sur l'hôte d'assembly. Ce n'est pas aussi sûr que les conteneurs, il est donc préférable de faire défiler la documentation de sécurité pour ne rien manquer.

 sudo curl --output /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-darwin-amd64 sudo chmod +x /usr/local/bin/gitlab-runner cd ~ gitlab-runner install gitlab-runner start 

Le trousseau Apple doit être configuré sur cet hôte avec accès aux clés que Xcode doit construire. Le moyen le plus simple de tester cela est de se connecter en tant qu'utilisateur qui démarre la génération et d'essayer de générer manuellement. Si le système demande l'accès au trousseau, sélectionnez Toujours autoriser le CI à fonctionner. Il peut être utile d'entrer et d'observer la première paire de pipelines, pour vous assurer qu'ils ne demandent plus un trousseau de clés. Le problème est qu'Apple ne nous facilite pas le travail avec le mode automatique, mais lorsque vous le réparerez, tout ira bien.

Fastlane init

Pour utiliser fastlane dans un projet, exécutez fastlane init . Suivez simplement les instructions d'installation et de démarrage de Fastlane , en particulier dans la section Gemfile , car nous avons besoin d'un lancement rapide et prévisible via le pipeline CI automatique.

Dans le répertoire du projet, exécutez ces commandes:

 xcode-select --install sudo gem install fastlane -NV # Alternatively using Homebrew # brew cask install fastlane fastlane init 

fastlane vous demandera la configuration de base, puis créera un dossier fastlane dans le projet avec trois fichiers:

1. fastlane/Appfile

Rien de compliqué ici. Assurez-vous simplement que l'ID Apple et l'ID d'application sont corrects.

 app_identifier("com.vontrance.flappybird") # The bundle identifier of your app apple_id("your-email@your-domain.com") # Your Apple email address 

2. fastlane/Fastfile

Fastfile définit les étapes de construction. Nous utilisons de nombreuses fonctionnalités Fastlane intégrées, donc tout est clair ici aussi. Créez une ligne qui reçoit les certificats, les compile et les charge dans TestFlight. Vous pouvez diviser ce processus en différentes tâches, si nécessaire. Toutes ces opérations ( get_certificates , get_provisioning_profile , gym et upload_to_testflight ) sont déjà incluses dans fastlane.

Les get_provisioning_profile get_certificates et get_provisioning_profile sont liées à l'approche de signature cert et soupir . Si vous utilisez une correspondance ou autre chose, apportez une modification.

 default_platform(:ios) platform :ios do desc "Build the application" lane :flappybuild do get_certificates get_provisioning_profile gym upload_to_testflight end end 

3. fastlane/Gymfile

Il s'agit d'un fichier facultatif, mais je l'ai créé manuellement pour modifier le répertoire de sortie par défaut et placer la sortie dans le dossier actuel. Cela simplifie CI. Si vous êtes intéressé, lisez la gym et ses paramètres dans la documentation .

 https://docs.fastlane.tools/actions/gym/ 

Notre .gitlab-ci.yml

Nous avons donc un coureur CI pour le projet et nous sommes prêts à tester le pipeline. Voyons ce que nous avons dans .gitlab-ci.yml :

 stages: - build variables: LC_ALL: "en_US.UTF-8" LANG: "en_US.UTF-8" GIT_STRATEGY: clone build: stage: build script: - bundle install - bundle exec fastlane flappybuild artifacts: paths: - ./FlappyBird.ipa 

Tout est super! Nous définissons le format UTF-8 pour fastlane, selon les besoins , utilisons la stratégie de clone avec l'exécutable shell afin d'avoir un espace de travail propre pour chaque assemblage, et appelons simplement flappybuild fastlane, comme vu ci-dessus. En conséquence, nous obtenons l'assemblage, la signature et le déploiement du dernier assemblage dans TestFlight.

Nous récupérons également l'artefact et l'enregistrons avec l'assemblage. Notez que le format .ipa est un exécutable ARM signé qui ne s'exécute pas dans le simulateur. Si vous souhaitez la sortie du simulateur, ajoutez simplement la cible d'assemblage qui la produit, puis incluez-la dans le chemin d'accès à l'artefact.

Autres variables d'environnement

Il y a quelques variables d'environnement sur lesquelles tout fonctionne.

FASTLANE_APPLE_APPLICATION_SPECIFIC_PASSWORD et FASTLANE_SESSION

L'authentification dans l'App Store et le téléchargement vers TestFlight nécessitent une authentification pour fastlane. Pour ce faire, créez un mot de passe pour l'application qui sera utilisée dans CI. Détails ici .

Si vous disposez d'une authentification à deux facteurs, créez la variable FASTLANE_SESSION (instructions ici).

FASTLANE_USER et FASTLANE_PASSWORD

Pour que cert et soupir appellent le profil d'initialisation et les certificats à la demande, les variables FASTLANE_USER et FASTLANE_PASSWORD doivent être définies. Détails ici . Cela n'est pas nécessaire si vous utilisez une méthode de signature différente.

En conclusion

Vous pouvez voir comment tout cela fonctionne dans mon exemple simple .

J'espère que cela a été utile et je vous ai inspiré pour travailler avec des builds iOS dans le projet GitLab. Voici quelques conseils CI supplémentaires pour Fastlane, au cas où. Vous souhaiterez peut-être utiliser CI_BUILD_ID (pour les versions incrémentielles) pour incrémenter automatiquement la version .

Une autre fonctionnalité intéressante de fastlane est les captures d' écran automatiques pour l'App Store, qui sont très faciles à configurer.

Partagez vos expériences dans les commentaires et partagez des idées pour améliorer le développement d'applications GitLab pour iOS.