Wir veröffentlichen iOS-Anwendungen im App Store mit GitLab und fastlane.

Wir veröffentlichen iOS-Anwendungen im App Store mit GitLab und fastlane.

Wie GitLab mit fastlane Anwendungen für iOS im App Store erstellt, signiert und veröffentlicht.

Kürzlich hatten wir einen Beitrag darüber, wie man schnell eine Android-Anwendung mit GitLab und fastlane. Hier sehen wir, wie man eine iOS-Anwendung erstellt und sie in TestFlight veröffentlicht. Schaut euch an, wie cool ich eine Änderung auf dem iPad Pro mit GitLab Web IDE vornehme, eine Build erstelle und das Update der Testversion der App auf demselben iPad Pro erhalte, auf dem ich sie entwickelt habe.

Hier verwenden wir eine einfache iOS-Anwendung in Swift, mit der ich ein Video aufgenommen habe.

Ein paar Worte zur Konfiguration des Apple Stores

Wir benötigen eine App im App Store, Vertriebszertifikate und ein Provisioning-Profil, um alles miteinander zu verknüpfen.

Das Schwierigste hierbei ist, die Signaturrechte im App Store einzurichten. Ich hoffe, dass ihr das selbst hinbekommt. Wenn ihr neu seid, werde ich die nötige Richtung angeben, aber hier wollen wir nicht über die Feinheiten des Umgangs mit Apple-Zertifikaten sprechen, da sich diese ständig ändern. Dieser Beitrag soll euch den Einstieg erleichtern.

Meine Anwendungen

Ihr benötigt eine App im App Store Connect, damit ihr eine ID für die Konfiguration habt .xcodebuild. Das Profil und die App-ID verbinden die Code-Builds, Preise und Verfügbarkeit sowie die TestFlight-Konfiguration für die Verbreitung von Testanwendungen an Benutzer. Macht keine öffentliche Testphase, es reicht aus, die private zu verwenden, wenn ihr eine kleine Gruppe habt, die Einrichtung einfach ist und keine weiteren Genehmigungen von Apple benötigt werden.

Provisioning-Profil

Neben der App-Einrichtung benötigt ihr Vertriebs- und Entwicklungs-Keys für iOS, die im Bereich Certificates, Identifiers & Profiles in der Apple Developer Console erstellt wurden. Alle diese Zertifikate können in einem Provisioning-Profil zusammengefasst werden.

Benutzer, die sich authentifizieren wollen, benötigen die Möglichkeit, Zertifikate zu erstellen, sonst seht ihr bei den Schritten cert und sigh einen Fehler.

Weitere Optionen

Neben dieser einfachen Methode gibt es auch andere Möglichkeiten, die Zertifikate und Profile einzurichten. Wenn ihr also anders arbeitet, müsst ihr möglicherweise umdenken. Am wichtigsten ist, dass ihr eine Konfiguration benötigt, .xcodebuild, die auf die erforderlichen Dateien verweist, und der Schlüsselbund muss auf dem Build-PC für den Benutzer, unter dessen Namen der Runner läuft, zugänglich sein. Für die digitale Signatur verwenden wir fastlane, und falls es Probleme gibt oder ihr mehr wissen möchtet, untersucht deren ausführliche Dokumentation zu digitalen Signaturen.

In diesem Beispiel verwende ich den Ansatz cert und sigh, aber für die praktische Anwendung ist wahrscheinlich besser geeignet match.

Vorbereitung von GitLab und fastlane

Vorbereitung des CI-Runners

Nachdem alle diese Daten gesammelt sind, fahren wir mit der Konfiguration des GitLab-Runners auf dem MacOS-Gerät fort. Leider ist die Entwicklung von iOS-Anwendungen tatsächlich nur auf MacOS möglich. Aber alles kann sich ändern, und wenn Sie auf Fortschritte in diesem Bereich warten, - folgen Sie den Projekten wie xcbuild und isign, und unserer internen Aufgabe gitlab-ce#57576.

Die Konfiguration des Runners ist sehr einfach. Befolgen Sie die aktuellen Anweisungen zur Konfiguration von GitLab Runner in macOS.

Hinweis. Der Runner muss das ausführbare Programm shellverwenden. Das ist notwendig, um iOS in macOS zu bauen, um direkt als Benutzer zu arbeiten und nicht über Container. Wenn Sie shell, erfolgt der Build und die Tests im Namen des Runner-Benutzers, direkt auf dem Build-Host. Das ist nicht so sicher wie Container, also scrollen Sie besser durch die Sicherheitsdokumentation, um nichts zu verpassen.

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

Die Apple Keychain muss auf diesem Host mit Zugriff auf die Schlüssel konfiguriert sein, die Xcode für den Build benötigt. Der einfachste Weg, dies zu testen, besteht darin, sich als Benutzer anzumelden, der den Build ausführt, und zu versuchen, den Build manuell durchzuführen. Wenn das System nach dem Zugriff auf die Schlüsselbund fragt, wählen Sie "Immer erlauben", damit CI funktioniert. Es könnte sinnvoll sein, sich anzumelden und die ersten paar Pipelines zu beobachten, um sicherzustellen, dass sie nicht mehr nach der Schlüsselbund fragen. Das Problem ist, dass Apple uns die Arbeit im automatischen Modus nicht erleichtert, aber sobald Sie es eingerichtet haben, wird alles gut sein.

fastlane init

Um fastlane im Projekt zu verwenden, starten Sie fastlane init. Folgen Sie einfach den Installations- und Startanweisungen für fastlane, insbesondere im Abschnitt über Gemfile, denn wir benötigen einen schnellen und vorhersehbaren Start über die CI-Pipeline.

Führen Sie diese Befehle im Projektverzeichnis aus:

xcode-select --install
sudo gem install fastlane -NV
# Alternativ mit Homebrew
# brew cask install fastlane
fastlane init

fastlane wird nach einer grundlegenden Konfiguration fragen und dann im Projekt einen Ordner fastlane mit drei Dateien erstellen:

1. fastlane/Appfile

Hier gibt es nichts Schwieriges. Überprüfen Sie einfach, ob die Apple ID und die App-ID korrekt angegeben sind.

app_identifier("com.vontrance.flappybird") # Die Bundle-ID Ihrer App
apple_id("your-email@your-domain.com") # Ihre Apple-E-Mail-Adresse

2. fastlane/Fastfile

Fastfile definiert die Schritte zum Build. Wir verwenden viele der integrierten Funktionen von fastlane, daher ist alles hier ebenfalls klar. Wir erstellen eine Zeile, die Zertifikate abruft, den Build ausführt und ihn in TestFlight hochlädt. Sie können diesen Prozess auf verschiedene Aufgaben aufteilen, wenn nötig. Alle diese Operationen (get_certificates, get_provisioning_profile, gym und upload_to_testflight) sind bereits in fastlane enthalten.

Aktionen get_certificates und get_provisioning_profile sind mit dem Signaturansatz verbunden cert und sigh. Wenn Sie match oder etwas anderes verwenden, bringen Sie Änderungen ein.

default_platform(:ios)

platform :ios do
  desc "Bauen der Anwendung"
  lane :flappybuild do
    get_certificates
    get_provisioning_profile
    gym
    upload_to_testflight
  end
end

3. fastlane/Gymfile

Dies ist eine optionale Datei, aber ich habe sie manuell erstellt, um das Standard-Ausgabeverzeichnis zu ändern und die Ausgaben in den aktuellen Ordner zu legen. Das vereinfacht CI. Wenn Sie interessiert sind, lesen Sie über gym und seine Parameter in Dokumentation.

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

Unser .gitlab-ci.yml

Also haben wir einen CI-Runner für das Projekt und sind bereit, die Pipeline zu testen. Sehen wir, was wir in .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

Alles läuft hervorragend! Wir setzen das UTF-8-Format für fastlane, wie erforderlich, verwenden eine Strategie clone mit der ausführbaren Datei shell, damit wir einen sauberen Arbeitsbereich für jeden Build haben, und rufen einfach flappybuild fastlane auf, wie oben zu sehen ist. Am Ende erhalten wir den Build, die Signatur und das Deployment des letzten Builds in TestFlight.

Außerdem erhalten wir das Artefakt und speichern es mit dem Build. Beachten Sie, dass das Format .ipa — das ein signiertes ARM-Ausführungsfile ist, das im Simulator nicht gestartet werden kann. Wenn Sie Ausgaben für den Simulator möchten, fügen Sie einfach ein Build-Target hinzu, das es erstellt, und schließen Sie es dann im Artefaktpfad ein.

Andere Umgebungsvariablen

Hier gibt es ein paar Umgebungsvariablen, auf denen alles basiert.

FASTLANE_APPLE_APPLICATION_SPECIFIC_PASSWORD und FASTLANE_SESSION

Für die Authentifizierung im App Store und den Upload in TestFlight benötigt fastlane eine Authentifizierung. Erstellen Sie dafür ein Anwendungskennwort, das in CI verwendet wird. Einzelheiten hier.

Wenn Sie die Zwei-Faktor-Authentifizierung haben, erstellen Sie eine Variable FASTLANE_SESSION (Anweisungen dort ebenfalls).

FASTLANE_USER und FASTLANE_PASSWORD

Um cert und sigh haben das Initialisierungsprofil und die Zertifikate auf Anfrage abgerufen, müssen Sie Variablen angeben FASTLANE_USER und FASTLANE_PASSWORD. Einzelheiten hier. Dies ist nicht erforderlich, wenn Sie eine andere Signaturmethode verwenden.

Abschließend

Schau dir an, wie das alles funktioniert in meinem einfachen Beispiel.

Ich hoffe, das war hilfreich und ich konnte euch inspirieren, mit den iOS-Builds im GitLab-Projekt zu arbeiten. Hier sind noch Tipps zu CI für fastlane, falls ihr es verwenden möchtet. CI_BUILD_ID (für inkrementelle Builds), um die Version automatisch zu inkrementieren..

Eine weitere coole Funktion von fastlane ist automatische Screenshots für den App Store, die sehr einfach einzurichten sind.

Teilt eure Erfahrungen in den Kommentaren und gebt Ideen zur Verbesserung von GitLab für die Entwicklung von iOS-Anwendungen bekannt.

Quelle: habr.com

60GB SSD 8Gb DDR4