
Wie GitLab mit fastlane Anwendungen für iOS im App Store erstellt, signiert und veröffentlicht.
Kürzlich hatten wir einen mit GitLab und . Hier sehen wir, wie man eine iOS-Anwendung erstellt und sie in TestFlight veröffentlicht. Schaut euch an, wie cool , eine Build erstelle und das Update der Testversion der App auf demselben iPad Pro erhalte, auf dem ich sie entwickelt habe.
Hier verwenden wir , 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 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 .
In diesem Beispiel verwende ich den Ansatz , aber für die praktische Anwendung ist wahrscheinlich besser geeignet .
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 und , und unserer internen Aufgabe .
Die Konfiguration des Runners ist sehr einfach. Befolgen Sie die aktuellen .
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 , 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 startDie 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 , insbesondere im Abschnitt über , 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 initfastlane 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-Adresse2. 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 . Wenn Sie 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
end3. 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 .
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.ipaAlles läuft hervorragend! , 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 .
Wenn Sie die Zwei-Faktor-Authentifizierung haben, erstellen Sie eine Variable FASTLANE_SESSION (Anweisungen dort ebenfalls).
FASTLANE_USER und FASTLANE_PASSWORD
Um haben das Initialisierungsprofil und die Zertifikate auf Anfrage abgerufen, müssen Sie Variablen angeben FASTLANE_USER und FASTLANE_PASSWORD. Einzelheiten . Dies ist nicht erforderlich, wenn Sie eine andere Signaturmethode verwenden.
Abschließend
Schau dir an, wie das alles funktioniert .
Ich hoffe, das war hilfreich und ich konnte euch inspirieren, mit den iOS-Builds im GitLab-Projekt zu arbeiten. Hier sind noch für fastlane, falls ihr es verwenden möchtet. CI_BUILD_ID (für inkrementelle Builds), um .
Eine weitere coole Funktion von fastlane ist 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
