Publiserer iOS-apper til App Store med GitLab og fastlane

Hvordan GitLab med fastlane samler inn, signerer og publiserer iOS-applikasjoner til App Store.

Vi hadde nylig innlegg om hvordan du raskt bygger og kjører en Android-applikasjon med GitLab og Fastlane. Her vil vi se hvordan du bygger og kjører en iOS-app og publiserer den til TestFlight. Sjekk hvor kult det er Jeg gjør en endring på en iPad Pro med GitLab Web IDE, tar jeg monteringen og får en oppdatering til testversjonen av applikasjonen på samme iPad Pro der jeg utviklet den.

Her tar vi enkel iOS-app på Swift, som jeg spilte inn videoen med.

Noen få ord om Apple Store-konfigurasjonen

Vi trenger en App Store-app, distribusjonssertifikater og en klargjøringsprofil for å knytte alt sammen.

Det vanskeligste her er å sette opp signeringsrettigheter i App Store. Jeg håper du kan finne ut av dette selv. Hvis du er ny, vil jeg peke deg i riktig retning, men vi vil ikke snakke om vanskelighetene med å administrere Apple-sertifikater her, og de endrer seg hele tiden. Dette innlegget vil hjelpe deg i gang.

Mine apper

Du trenger en app i App Store Connect slik at du har en ID for konfigurasjon .xcodebuild. Profilen og applikasjons-IDen kombinerer kodebygg, priser og tilgjengelighet, og TestFlight-konfigurasjon for distribusjon av testapplikasjoner til brukere. Ikke gjør offentlig testing, privat testing vil være tilstrekkelig hvis du har en liten gruppe, enkelt oppsett og ikke trenger ytterligere tillatelser fra Apple.

Initialiseringsprofil

I tillegg til appoppsettet trenger du iOS-distribusjons- og utviklingsnøkler som er opprettet i sertifikater, identifikatorer og profiler i Apples utviklerkonsoll. Alle disse sertifikatene kan kombineres til en klargjøringsprofil.

Brukere som skal autentiseres må kunne opprette sertifikater, ellers trinnene cert og sukk vil du se en feil.

andre alternativer

Bortsett fra denne enkle metoden, er det andre måter å konfigurere sertifikater og profiler på. Så hvis du jobber annerledes, må du kanskje tilpasse deg. Det viktigste er at du trenger konfigurasjon .xcodebuild, som vil peke til de nødvendige filene, og nøkkelringen må være tilgjengelig på byggedatamaskinen for brukeren som kjører under navnet. For digital signatur bruker vi fastlane, og hvis det er problemer eller du vil vite mer, sjekk ut detaljene deres dokumentasjon om digitale signaturer.

I dette eksemplet bruker jeg tilnærmingen cert og sukk, men for ekte bruk er den sannsynligvis bedre egnet kamp.

Forbereder GitLab og fastlane

Forbereder CI Runner

Etter å ha samlet inn alle disse dataene, går vi videre til konfigurasjonen av GitLab-løperen på MacOS-enheten. Dessverre kan du bare lage iOS-apper på MacOS. Men alt kan endre seg, og hvis du forventer fremgang på dette området, hold øye med prosjekter som xcbuild и skilt, og vår interne oppgave gitlab-ce#57576.

Å sette opp løperen er veldig enkelt. Følg det siste instruksjoner for å sette opp GitLab Runner på macOS.

Merk. Løperen må bruke et kjørbart program shell. Dette er nødvendig for å bygge iOS på macOS for å fungere direkte som bruker i stedet for gjennom containere. Hvis du bruker shell, bygging og testing utføres som løperbruker, direkte på byggeverten. Det er ikke så sikkert som containere, så det er best å bla sikkerhetsdokumentasjonså du ikke går glipp av noe.

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

Apple Keychain må konfigureres på denne verten med tilgang til nøklene som Xcode må bygge. Den enkleste måten å teste dette på er å logge på som brukeren som skal kjøre bygget og prøve å bygge det manuelt. Hvis systemet ber om nøkkelringtilgang, velger du Alltid tillat at CI fungerer. Det kan være verdt å gå inn og se på de første par rørledningene for å være sikker på at de ikke ber om nøkkelringen lenger. Problemet er at Apple ikke gjør det enkelt for oss å bruke Auto-modus, men når du først får det i gang, vil alt gå bra.

fastlane init

For å bruke fastlane i et prosjekt, kjør fastlane init. Bare følg instruksjoner for å installere og kjøre fastlane, spesielt i avsnittet om Gemfile, fordi vi trenger rask og forutsigbar lansering gjennom en automatisert CI-pipeline.

Kjør disse kommandoene i prosjektkatalogen din:

xcode-select --install
sudo gem install fastlane -NV
# Alternatively using Homebrew
# brew cask install fastlane
fastlane init

fastlane vil be om en grunnleggende konfigurasjon og deretter opprette en fastlane-mappe i prosjektet med tre filer:

1. fastlane/Appfile

Det er ikke noe komplisert her. Bare sørg for at Apple ID og App ID er riktige.

app_identifier("com.vontrance.flappybird") # The bundle identifier of your app
apple_id("[email protected]") # Your Apple email address

2. fastlane/Fastfile

Fastfile definerer byggetrinnene. Vi bruker mye av fastlanes innebygde funksjoner, så alt er klart her også. Vi lager én linje som mottar sertifikater, utfører monteringen og laster den opp til TestFlight. Du kan dele denne prosessen inn i ulike oppgaver om nødvendig. Alle disse operasjonene (get_certificates, get_provisioning_profile, gym и upload_to_testflight) er allerede inkludert i fastlane.

Aktivitet get_certificates и get_provisioning_profile knyttet til signeringsmetoden cert og sukk. Hvis du bruker kamp eller hva som helst, gjør endringer.

default_platform(:ios)

platform :ios do
  desc "Build the application"
  lane :flappybuild do
    get_certificates
    get_provisioning_profile
    gym
    upload_to_testflight
  end
end

3. fastlane/Gymfile

Dette er en valgfri fil, men jeg opprettet den manuelt for å endre standard utdatakatalog og plassere utdataene i gjeldende mappe. Dette forenkler CI. Hvis du er interessert, les om gym og dens parametere i dokumentasjon.

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

Ours .gitlab-ci.yml

Så vi har en CI-løper for prosjektet, og vi er klare til å teste rørledningen. La oss se hva 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.ipa

Все отлично! Vi setter formatet til UTF-8 for fastlane etter behov, bruk strategi clone med kjørende program shell, slik at vi har en ren arbeidsplass for hver montering, og ringer bare flappybuild fastlane, som vist ovenfor. Som et resultat får vi montering, signatur og distribusjon av den siste sammenstillingen i TestFlight.

Vi henter også artefakten og lagrer den sammen med monteringen. Vær oppmerksom på at formatet .ipa er en signert ARM-kjørbar som ikke kjører i simulatoren. Hvis du vil ha utdata for simulatoren, legger du bare til byggemålet som produserer det, og inkluderer det i artefaktbanen.

Andre miljøvariabler

Det er et par miljøvariabler her som gjør at alt fungerer.

FASTLANE_APPLE_APPLICATION_SPECIFIC_PASSWORD и FASTLANE_SESSION

Autentisering for fastlane kreves for å autentisere i App Store og laste opp til TestFlight. For å gjøre dette, lag et passord for applikasjonen som skal brukes i CI. Detaljer her.

Hvis du har tofaktorautentisering, lag en variabel FASTLANE_SESSION (instruksjoner der).

FASTLANE_USER и FASTLANE_PASSWORD

At cert og sukk kalt initialiseringsprofilen og sertifikater på forespørsel, må du angi variablene FASTLANE_USER и FASTLANE_PASSWORD. Detaljer her. Dette er ikke nødvendig hvis du bruker en annen signeringsmetode.

i konklusjonen

Du kan se hvordan det hele fungerer i mitt enkle eksempel.

Jeg håper dette var nyttig og inspirerte deg til å jobbe med iOS-bygg i et GitLab-prosjekt. Her er en annen CI tips for fastlane, for sikkerhets skyld. Det kan være lurt å bruke CI_BUILD_ID (for inkrementelle bygg) til automatisk øke versjonen.

En annen kul funksjon i fastlane er automatiske skjermbilder for App Store, som er veldig enkle å sette opp.

Fortell oss i kommentarene om opplevelsen din og del ideene dine for å forbedre GitLab for iOS-apputvikling.

Kilde: www.habr.com