🥇Publions des applications iOS dans l'App Store avec GitLab et fastlane

Comment GitLab et fastlane construisent, signent et publient des applications iOS sur l'App Store.

Récemment, nous avons eu un article sur la façon de construire et de lancer rapidement une application Android avec GitLab et fastlane.Ici, nous verrons comment construire et lancer une application iOS et la publier sur TestFlight. Découvrez à quel point c'est génial. J'apporte une modification sur l'iPad Pro avec GitLab Web IDE, je prends le build et obtiens la mise à jour de la version beta de l'application sur le même iPad Pro où je l'ai développée.

Ici, nous prendrons une simple application iOS en 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'approvisionnement pour tout relier.

Le plus difficile ici est de configurer les droits de signature dans l'App Store. J'espère que vous pourrez vous débrouiller. Si vous êtes débutant, je vous indiquerai la bonne direction, mais nous ne parlerons pas ici des subtilités de gestion des certificats Apple, qui changent constamment. Cet article vous aidera à démarrer.

Mes applications

Vous aurez besoin d'une application dans App Store Connect pour avoir un ID pour la configuration .xcodebuild.Le profil et l'ID de l'application relient les builds de code, les prix et la disponibilité, ainsi que la configuration de TestFlight pour la distribution des applications beta aux utilisateurs. Ne faites pas de test public ; un test privé suffira si vous avez un petit groupe, une configuration simple et pas besoin d'autorisations supplémentaires d'Apple.

Profil d'approvisionnement

En plus de la configuration de l'application, vous aurez besoin de clés de distribution et de développement iOS, créées dans la section Certificates, Identifiers & Profiles dans la console Apple Developer. Tous ces certificats peuvent être combinés dans un profil d'approvisionnement.

Les utilisateurs qui doivent s'authentifier ont besoin de la possibilité de créer des certificats, sinon, aux étapes cert et sigh vous verrez une erreur.

Autres options

En plus de cette méthode simple, il existe d'autres façons de configurer des certificats et des profils. Donc, si vous travaillez différemment, il se peut que vous deviez vous réorganiser. L'essentiel est que vous aurez besoin d'une configuration .xcodebuild., qui pointera vers les fichiers nécessaires, et le trousseau doit être disponible sur l'ordinateur de construction pour l'utilisateur sous le nom duquel le runner fonctionne. Pour la signature numérique, nous utilisons fastlane, et s'il y a des problèmes ou si vous voulez en savoir plus, consultez leurs détails. documentation sur les signatures électroniques.

Dans cet exemple, j'utilise une approche cert et sigh, mais pour une application réelle, il serait probablement préférable d'utiliser match.

Préparation de GitLab et fastlane

Préparation du CI Runner

Après avoir rassemblé toutes ces données, nous passons à la configuration du GitLab Runner sur un appareil MacOS. Malheureusement, il est réellement possible de créer des applications iOS uniquement sur MacOS. Mais tout peut changer, et si vous attendez des avancées dans ce domaine, suivez les projets comme xcbuild et isign, et notre tâche interne gitlab-ce#57576.

Configurer le runner est très simple. Suivez les instructions actuelles pour configurer GitLab Runner sur macOS.

Remarque. Le runner doit utiliser le programme exécutable shell. C'est indispensable pour la construction d'iOS sur macOS, afin de fonctionner directement en tant qu'utilisateur, et non via des conteneurs. Si vous utilisez shell, la construction et les tests sont exécutés au nom de l'utilisateur du runner, directement sur l'hôte de construction. Ce n'est pas aussi sûr que les conteneurs, donc il vaut mieux vérifier la documentation sur la 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 nécessaires pour Xcode afin de construire. La manière la plus simple de tester cela est de se connecter en tant qu'utilisateur qui exécutera la build et d'essayer d'effectuer la construction manuellement. Si le système demande l'accès au trousseau, choisissez « Toujours autoriser » pour que le CI fonctionne. Il peut être judicieux de se connecter et d'observer les premières paires de pipelines, pour s'assurer qu'ils ne demandent plus de trousseau. Le problème est qu'Apple ne nous facilite pas le travail avec le mode automatique, mais une fois que vous l'avez configuré, tout ira bien.

fastlane init

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

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

xcode-select --install
sudo gem install fastlane -NV
# Alternativement, en utilisant Homebrew
# brew cask install fastlane
fastlane init

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

1. fastlane/Appfile

Il n'y a rien de compliqué ici. Vérifiez simplement que l'Apple ID et l'ID de l'application sont correctement renseignés.

app_identifier("com.vontrance.flappybird") # L'identifiant de bundle de votre application
apple_id("your-email@your-domain.com") # Votre adresse email Apple

2. fastlane/Fastfile

Fastfile définit les étapes de construction. Nous utilisons beaucoup de fonctionnalités intégrées de fastlane, donc tout est clair ici. Nous créons une ligne qui obtient les certificats, exécute la construction et la télécharge sur 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.

Actions get_certificates et get_provisioning_profile sont liées à l'approche de signature cert et sigh. Si vous utilisez match ou autre chose, faites les modifications.

default_platform(:ios)

platform :ios do
  desc "Construire l'application"
  lane :flappybuild do
    get_certificates
    get_provisioning_profile
    gym
    upload_to_testflight
  end
end

3. fastlane/Gymfile

C'est un fichier optionnel, mais je l'ai créé manuellement pour changer le répertoire de sortie par défaut et placer la sortie dans le dossier actuel. Cela simplifie le CI. Si vous êtes intéressé, lisez à propos de gym et de ses paramètres dans documentation.

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

Notre .gitlab-ci.yml

Donc, nous avons un CI-runner pour le projet, et nous sommes prêts à tester le pipeline. Regardons 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 parfait ! Nous définissons le format UTF-8 pour fastlane, comme requis, en utilisant la stratégie clone avec l'exécutable shell, afin d'avoir un espace de travail propre pour chaque construction, et nous appelons simplement flappybuild fastlane, comme indiqué ci-dessus. En fin de compte, nous obtenons une construction, une signature et un déploiement de la dernière construction sur TestFlight.

Nous obtenons également un artefact et le sauvegardons avec la construction. Notez que le format .ipa est un fichier exécutable ARM signé, qui ne s'exécute pas sur l'émulateur. Si vous voulez des sorties pour l'émulateur, ajoutez simplement une cible de construction qui le produit, puis incluez-la dans le chemin de l'artefact.

Autres variables d'environnement

Voici quelques variables d'environnement sur lesquelles tout repose.

FASTLANE_APPLE_APPLICATION_SPECIFIC_PASSWORD et FASTLANE_SESSION

Pour l'authentification dans l'App Store et le téléchargement sur TestFlight, une authentification pour fastlane est nécessaire. Pour cela, créez un mot de passe spécifique à l'application qui sera utilisé dans le CI. Plus de détails ici.

Si vous avez l'authentification à deux facteurs, créez une variable FASTLANE_SESSION (les instructions sont également là).

FASTLANE_USER et FASTLANE_PASSWORD

Pour que cert et sigh les certificats et le profil de provisioning soient appelés à la demande, il est nécessaire de définir des variables FASTLANE_USER et FASTLANE_PASSWORD. Plus de détails ici. Cela n'est pas nécessaire si vous utilisez une autre méthode de signature.

En conclusion

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

J'espère que cela a été utile et que j'ai réussi à vous inspirer à travailler avec des builds iOS dans un projet GitLab. Voici encore des conseils sur CI pour fastlane, au cas où. Vous pourriez vouloir utiliser CI_BUILD_ID (pour des builds incrémentiels), afin de incrémenter automatiquement la version.

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

Parlez-nous dans les commentaires de votre expérience et partagez vos idées pour améliorer GitLab pour le développement d'applications iOS.

Source : habr.com

Nous publions des applications iOS dans l'App Store avec GitLab et fastlane