Hvordan GitLab med fastlane bygger, signer og offentliggør iOS-applikationer i App Store.
For nylig havde vi en med GitLab og Her vil vi se, hvordan man bygger og lancerer en iOS-applikation og publicerer den i TestFlight. Tjek hvor fantastisk , tager en bygning og får en opdatering af testversionen af applikationen på den samme iPad Pro, hvor jeg udviklede den.
Her vil vi tage , som jeg optog video med.
Et par ord om konfigurationen af Apple Store
Vi har brug for en applikation i App Store, distributionstilladelser og et initialiseringsprofil for at binde det hele sammen.
Det sværeste her er at konfigurere signeringsrettighederne i App Store. Jeg håber, at I kan finde ud af det selv. Hvis du er ny, angiver jeg den rigtige retning, men vi vil ikke diskutere detaljerne omkring Apples certifikatadministration her, og desuden ændrer de sig hele tiden. Dette indlæg hjælper dig med at komme i gang.
Mine appliaktioner
Du har brug for en applikation i App Store Connect for at få et ID til konfigurationen .xcodebuild. Profil og app-ID forbinder kodebygninger, priser og tilgængelighed, samt TestFlight-konfigurationen til distribution af testapplikationer til brugerne. Undlad at lave offentlig testning; privat testning er tilstrækkeligt, hvis du har en lille gruppe, enkel opsætning og ikke har brug for yderligere tilladelser fra Apple.
Initialiseringsprofil
Udover opsætningen af applikationen har du brug for distributions- og udviklingsnøgler til iOS, som er oprettet i sektionen Certificates, Identifiers & Profiles (Certifikater, identifikatorer og profiler) i Apple Developer-konsollen. Alle disse certifikater kan samles i en initialiseringsprofil.
Brugere, der skal autentificeres, har brug for muligheden for at oprette certifikater, ellers vil du se en fejl på trinene Andre muligheder
Udover denne enkle metode er der andre måder at konfigurere certifikater og profiler på. Så hvis du arbejder anderledes, kan det være nødvendigt at omarrangere. Det vigtigste er, at du har brug for en konfiguration
, som peger på de nødvendige filer, og nøglekæden skal være tilgængelig på bygningens computer for brugeren, hvis navn runneren kører under. Til digital signatur bruger vi fastlane, og hvis der er problemer, eller hvis du vil vide mere, så undersøg deres detaljerede dokumentation. .xcodebuild, которая будет указывать на нужные файлы, а связка ключей должна быть доступна на компьютере сборки для пользователя, под чьим именем работает раннер. Для цифровой подписи мы используем fastlane, и если есть проблемы или вы хотите узнать больше, изучите их подробную .
I dette eksempel bruger jeg en tilgang , men til rigtig anvendelse vil det nok være bedre at bruge .
Forberedelse af GitLab og fastlane
Forberedelse af CI Runner
Når vi har samlet alle disse data, går vi videre til konfigurationen af GitLab-runneren på en MacOS-enhed. Desværre kan man kun udvikle iOS-apps på MacOS. Men alt kan ændre sig, så hvis du venter på fremskridt på dette område, — følg projekter som og , og vores interne opgave .
Det er meget nemt at konfigurere runneren. Følg de aktuelle .
Bemærk: Runneren skal bruge programmet shell. Dette er nødvendigt for at bygge iOS i macOS, så det fungerer direkte som en bruger og ikke gennem containere. Hvis du bruger shell, udføres bygning og testning på vegne af runnerens bruger, direkte på build-hosten. Dette er ikke så sikkert som containere, så det er bedst at læse , så du ikke misser noget.
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 startApple-nøglebindingssystemet skal være konfigureret på denne host med adgang til de nøgler, som Xcode har brug for til at bygge. Den enkleste måde at teste dette på er at logge ind som brugeren, der skal udføre bygningen, og forsøge at køre en manuel bygning. Hvis systemet beder om adgang til nøglebindingen, skal du vælge 'Alltid tillad', så CI fungerer. Det kan være en god idé at logge ind og overvåge de første par pipelines for at sikre, at de ikke længere beder om nøglebindingen. Problemet er, at Apple ikke gør det nemt for os at arbejde i automatisk tilstand, men når du får det opsat, vil alt være i orden.
fastlane init
For at bruge fastlane i projektet skal du køre fastlane init. Følg bare , især sektionen om , da vi har brug for en hurtig og forudsigelig opstart gennem CI-pipelinen.
I projektmappen skal du køre følgende kommandoer:
xcode-select --install
sudo gem install fastlane -NV
# Alternativt ved brug af Homebrew
# brew cask install fastlane
fastlane initfastlane vil anmode om en grundlæggende konfiguration, og derefter oprette en mappe i projektet med navnet fastlane, som indeholder tre filer:
1. fastlane/Appfile
Der er ikke noget kompliceret ved dette. Tjek blot, at Apple ID og app-ID er angivet korrekt.
app_identifier("com.vontrance.flappybird") # Bundlet ID for din app
apple_id("your-email@your-domain.com") # Din Apple e-mail adresse2. fastlane/Fastfile
Fastfile definerer byggeprocessen. Vi bruger mange indbyggede funktioner i fastlane, så det er også klart her. Vi opretter en linje, der skaffer certifikater, udfører bygningen og uploader den til TestFlight. Du kan opdele denne proces i forskellige opgaver, hvis nødvendigt. Alle disse operationer (get_certificates, get_provisioning_profile, gym og upload_to_testflight) er allerede inkluderet i fastlane.
Handlinger get_certificates og get_provisioning_profile er relateret til signaturmetoden . Hvis du bruger eller noget andet, skal du foretage ændringer.
default_platform(:ios)
platform :ios do
desc "Byg applikationen"
lane :flappybuild do
get_certificates
get_provisioning_profile
gym
upload_to_testflight
end
end3. fastlane/Gymfile
Dette er en valgfri fil, men jeg oprettede den manuelt for at ændre standardoutputkataloget og placere outputtet i den aktuelle mappe. Det gør CI enklere. Hvis du er interesseret, læs om gym og dens parametre i .
https://docs.fastlane.tools/actions/gym/Vores .gitlab-ci.yml
Så vi har en CI-løber til projektet, og vi er klar til at teste pipeline. Lad os se, hvad vi har i .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.ipaDet ser godt ud! , bruger strategien clone med eksekveringsprogrammet shell, så vi har et rent arbejdsområde til hver bygning, og kalder simpelthen flappybuild fastlane, som vist ovenfor. I sidste ende får vi bygning, signatur og deployment af den seneste bygning til TestFlight.
Vi får også artefakten og gemmer den sammen med bygningen. Bemærk, at formatet .ipa — det er en signeret ARM eksekverbar fil, som ikke kan køre i simulatoren. Hvis du vil have output til simulatoren, skal du simpelthen tilføje en bygge-target, der producerer den, og så inkludere den i artefaktstien.
Andre miljøvariabler
Her er et par miljøvariabler, som alt arbejder på.
FASTLANE_APPLE_APPLICATION_SPECIFIC_PASSWORD og FASTLANE_SESSION
For autentificering i App Store og upload til TestFlight kræves autentificering for fastlane. For dette skal du oprette en applikationsspecifik adgangskode, der bruges i CI. Detaljer .
Hvis du har to-faktor-autentificering, skal du oprette en variabel FASTLANE_SESSION (instruktioner der).
FASTLANE_USER og FASTLANE_PASSWORD
For at har kaldt initiationsprofilen og certifikaterne efter anmodning; variablerne skal angives FASTLANE_USER og FASTLANE_PASSWORD. Detaljer . Dette er ikke nødvendigt, hvis du bruger en anden signaturmetode.
Afslutningsvis
Se hvordan det hele fungerer .
Jeg håber, dette var nyttigt, og jeg har inspireret dig til at arbejde med iOS-builds i dit GitLab-projekt. Her er nogle flere til fastlane, bare så du ved det. Måske ønsker du at bruge CI_BUILD_ID (til inkrementelle builds), for at .
En anden fed funktion i fastlane er til App Store, som er meget nemme at konfigurere.
Fortæl om dine erfaringer i kommentarerne, og del idéer til at forbedre GitLab til udvikling af iOS-apps.
Kilde: habr.com
