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

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

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

Kürzlich hatten wir einen Beitrag darüber, wie man schnell eine Android-Anwendung mit GitLab und fastlaneaufsetzt. Hier sehen wir, wie man eine iOS-Anwendung erstellt und sie in TestFlight veröffentlicht. Schaut mal, wie cool ich eine Änderung auf dem iPad Pro mit GitLab Web IDE einführe,die Build-Ausgabe anfordere und das Update der Testversion der Anwendung auf demselben iPad Pro erhalte, auf dem ich sie entwickelt habe.

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

Ein paar Worte zur Apple Store-Konfiguration

Wir benötigen eine App im App Store, Verteilungssignierungszertifikate und ein Initialisierungsprofil, um alles miteinander zu verknüpfen.

Das Schwierigste dabei ist, die Signaturrechte im App Store einzurichten. Ich hoffe, das bekommen Sie selbst hin. Wenn Sie neu sind, werde ich Ihnen den richtigen Weg zeigen, aber hier werden wir nicht über die Feinheiten der Verwaltung von Apple-Zertifikaten sprechen, da sich diese ständig ändern. Dieser Beitrag hilft Ihnen, den Einstieg zu finden.

Meine Anwendungen

Es wird eine App im App Store Connect benötigt, damit Sie eine ID zur Konfiguration haben. .xcodebuild. Das Profil und die App-ID kombinieren den Code, die Preise und die Verfügbarkeit sowie die TestFlight-Konfiguration für die Verteilung von Testanwendungen an Benutzer. Führen Sie kein öffentliches Testing durch; private Tests reichen aus, wenn Sie eine kleine Gruppe haben, eine einfache Einrichtung benötigen und keine zusätzlichen Genehmigungen von Apple erforderlich sind.

Initialisierungsprofil

Neben der App-Einrichtung benötigen Sie Veröffentlichungs- und Entwicklungs-Keys für iOS, die im Abschnitt Certificates, Identifiers & Profiles (Zertifikate, Identifikatoren und Profile) in der Apple Developer Konsole erstellt werden. Alle diese Zertifikate können im Initialisierungsprofil gebündelt werden.

Benutzer, die sich authentifizieren möchten, benötigen die Möglichkeit, Zertifikate zu erstellen; sonst sehen Sie bei den Phasen cert und sigh einen Fehler.

Weitere Optionen

Neben dieser einfachen Methode gibt es auch andere Möglichkeiten, Zertifikate und Profile einzurichten. Wenn Sie also anders arbeiten, müssen Sie möglicherweise umdenken. Am wichtigsten ist, dass Sie eine Konfiguration benötigen. .xcodebuild, die auf die benötigten Dateien verweist, und die Schlüsselverbindung muss auf dem Computer des Benutzers verfügbar sein, unter dessen Namen der Runner arbeitet. Für die digitale Signatur verwenden wir Fastlane, und wenn es Probleme gibt oder Sie mehr erfahren möchten, lesen Sie deren ausführliche Dokumentation zu digitalen Signaturen.

In diesem Beispiel benutze ich einen Ansatz cert und sigh, aber für die praktische Anwendung wäre wahrscheinlich besser geeignet Match.

Vorbereitung von GitLab und Fastlane

Vorbereitung des CI-Runners

Nachdem wir all diese Daten gesammelt haben, gehen wir zur Konfiguration des GitLab-Runners auf dem macOS-Gerät über. Leider ist die Entwicklung von iOS-Anwendungen tatsächlich nur auf macOS möglich. Aber das kann sich ändern, und wenn Sie Entwicklungen in diesem Bereich erwarten, verfolgen Sie Projekte wie Xcbuild и Isign, und unsere interne Aufgabe gitlab-ce#57576.

Die Einrichtung des Runners ist sehr einfach. Folgen Sie den aktuellen Einrichtungsanweisungen für GitLab Runner auf macOS.

Hinweis: Der Runner muss das ausführbare Programm Shell. verwenden. Dies ist für den iOS-Bau auf macOS unbedingt erforderlich, um direkt als Benutzer und nicht über Container zu arbeiten. Wenn Sie verwenden Shell, die Erstellung und Tests erfolgen im Namen des Benutzers des Runners direkt auf dem Build-Host. Dies ist nicht so sicher wie Container, also scrollen Sie besser nach unten. Sicherheitsdokumentation, um nichts zu übersehen.

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

Der Apple-Schlüsselbund muss auf diesem Host konfiguriert werden, um Zugriff auf die Schlüssel zu haben, die Xcode für den Build benötigt. Der einfachste Weg, dies zu testen, besteht darin, sich als Benutzer anzumelden, der den Build ausführen wird, und versuchen, den Build manuell auszuführen. Wenn das System den Zugriff auf den Schlüsselbund anfordert, wählen Sie „Immer erlauben“, damit CI funktioniert. Es kann sinnvoll sein, sich anzumelden und die ersten paar Pipelines zu beobachten, um sicherzustellen, dass sie nicht mehr nach dem Schlüsselbund fragen. Das Problem ist, dass Apple es uns nicht einfach macht, dies im automatischen Modus zu handhaben, aber sobald Sie es eingerichtet haben, wird alles gut sein.

fastlane init

Um fastlane im Projekt zu verwenden, führen Sie aus fastlane init. Folgen Sie einfach den Installations- und Ausführungsanweisungen für fastlane, insbesondere im Abschnitt über Gemfile, denn wir benötigen einen schnellen und vorhersehbaren Start über die automatische 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 der grundlegenden Konfiguration fragen und dann im Projektordner fastlane mit drei Dateien erstellen:

1. fastlane/Appfile

Hier ist nichts kompliziert. Überprüfen Sie einfach, dass die Apple-ID und die App-ID korrekt angegeben sind.

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

2. fastlane/Fastfile

Fastfile definiert die Schritte im Build-Prozess. Wir nutzen viele integrierte Funktionen von Fastlane, daher ist alles auch hier klar. Wir erstellen eine Zeile, die die Zertifikate abruft, das Build ausführt und in TestFlight hochlädt. Sie können diesen Prozess in verschiedene Aufgaben aufteilen, wenn nötig. Alle diese Operationen (get_certificates, get_provisioning_profile, gym и upload_to_testflight) sind bereits in Fastlane enthalten.

Aktionen get_certificates и get_provisioning_profile sind mit der Signaturmethode verbunden cert und sigh. Wenn Sie Match oder etwas anderes verwenden, nehmen Sie Änderungen vor.

default_platform(:ios)

platform :ios do
  desc "Baue die Anwendung"
  lane :flappybuild do
    get_certificates
    get_provisioning_profile
    gym
    upload_to_testflight
  end
end

3. fastlane/Gymfile

Dies ist eine optionale Datei, die ich manuell erstellt habe, um das Standard-Ausgabeverzeichnis zu ändern und die Ausgaben im aktuellen Ordner abzulegen. Das erleichtert die CI. Wenn Sie interessiert sind, lesen Sie über gym und seine Optionen in Dokumentation..

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

Unser .gitlab-ci.yml

Also, wir haben einen CI-Runner für das Projekt, und wir sind bereit, die Pipeline zu testen. Schauen wir, was wir in .gitlab-ci.yml:

stages:
  - build

variables:
  LC_ALL: "de_DE.UTF-8"
  LANG: "de_DE.UTF-8"
  GIT_STRATEGY: clone

build:
  stage: build
  script:
    - bundle install
    - bundle exec fastlane flappybuild
  artifacts:
    paths:
    - ./FlappyBird.ipa

Alles bestens! Wir setzen das UTF-8-Format für fastlane, wie erforderlich, verwenden die Strategie clone mit dem Executable Shell, damit wir ein sauberes Arbeitsumfeld für jeden Build haben, und rufen einfach flappybuild fastlane, wie oben sichtbar. Am Ende erhalten wir den Build, die Signatur und den Deployment der letzten Version in TestFlight.

Außerdem erhalten wir ein Artefakt und speichern es zusammen mit dem Build. Beachten Sie, dass das Format .ipa eine signierte ARM-Executable ist, die im Simulator nicht ausgeführt werden kann. Wenn Sie die Ausgaben für den Simulator wünschen, fügen Sie einfach das Build-Ziel hinzu, das es erstellt, und binden Sie es dann in den Artefaktpfad ein.

Weitere Umgebungsvariablen

Hier gibt es ein paar Umgebungsvariablen, auf denen alles läuft.

FASTLANE_APPLE_APPLICATION_SPECIFIC_PASSWORD и FASTLANE_SESSION

Für die Authentifizierung im App Store und das Hochladen in TestFlight benötigen Sie eine Authentifizierung für fastlane. Erstellen Sie dafür ein Anwendungspasswort, das in CI verwendet wird. Weitere Informationen hier.

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

FASTLANE_USER и FASTLANE_PASSWORD

Um cert und sigh Für die initialisierende Profil- und Zertifikatsanforderung müssen Variablen festgelegt werden FASTLANE_USER и FASTLANE_PASSWORD. Weitere Informationen hier. Dies ist nicht notwendig, wenn Sie ein anderes Signierungsverfahren verwenden.

Zusammenfassung

Sie können sehen, wie das Ganze funktioniert in meinem einfachen Beispiel.

Ich hoffe, das war hilfreich und hat Sie inspiriert, mit iOS-Builds in Ihrem GitLab-Projekt zu arbeiten. Hier sind noch einige Tipps für CI für fastlane, für den Fall, dass Sie CI_BUILD_ID (für inkrementelle Builds) verwenden möchten, um die Version automatisch zu inkrementieren.

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

Teilen Sie Ihre Erfahrungen in den Kommentaren und bringen Sie Ideen zur Verbesserung von GitLab für die Entwicklung von iOS-Anwendungen ein.

Quelle: habr.com

Купить надежный хостинг для сайтов с защитой от DDoS, VPS VDS серверы 🔥 Купить надежный хостинг для сайтов с защитой от DDoS, VPS VDS серверы | ProHoster