ProHoster > Blog > Pangangasiwa > Pag-publish ng mga iOS application sa App Store gamit ang GitLab at fastlane

Pag-publish ng mga iOS application sa App Store gamit ang GitLab at fastlane

Pag-publish ng mga iOS application sa App Store gamit ang GitLab at fastlane

Paano kinokolekta, pinipirmahan at ini-publish ng GitLab na may fastlane ang mga iOS application sa App Store.

Nagkaroon kami kamakailan mag-post tungkol sa kung paano mabilis na bumuo at magpatakbo ng isang Android application kasama ang GitLab at mabilis na daanan. Dito natin makikita kung paano bumuo at magpatakbo ng iOS app at i-publish ito sa TestFlight. Tingnan kung gaano ito kaastig Gumagawa ako ng pagbabago sa isang iPad Pro gamit ang GitLab Web IDE, kinuha ko ang pagpupulong at kumuha ng update sa pagsubok na bersyon ng application sa parehong iPad Pro kung saan ko ito binuo.

Dito kami kukuha simpleng iOS app sa Swift, kung kanino ako nag-record ng video.

Ilang salita tungkol sa configuration ng Apple Store

Kakailanganin namin ang isang App Store app, mga sertipiko ng pamamahagi, at isang provisioning profile upang pagsama-samahin ang lahat.

Ang pinakamahirap na bagay dito ay ang pagse-set up ng mga karapatan sa pag-sign sa App Store. Umaasa ako na maaari mong malaman ito para sa iyong sarili. Kung bago ka, ituturo ko sa iyo ang tamang direksyon, ngunit hindi namin pag-uusapan ang tungkol sa mga intricacies ng pamamahala ng mga Apple certificate dito, at patuloy silang nagbabago. Tutulungan ka ng post na ito na makapagsimula.

Aking Mga App

Kailangan mo ng app sa App Store Connect para magkaroon ka ng ID para sa configuration .xcodebuild. Pinagsasama ng profile at application ID ang mga build ng code, pagpepresyo at availability, at configuration ng TestFlight para sa pamamahagi ng mga application ng pagsubok sa mga user. Huwag gumawa ng pampublikong pagsubok, sapat na ang pribadong pagsubok kung mayroon kang maliit na grupo, madaling pag-setup, at hindi kailangan ng mga karagdagang pahintulot mula sa Apple.

Profile ng pagsisimula

Bilang karagdagan sa setup ng app, kailangan mo ng iOS distribution at development key na ginawa sa seksyong Mga Certificate, Identifier, at Profile ng Apple Developer console. Ang lahat ng mga certificate na ito ay maaaring pagsamahin sa isang provisioning profile.

Ang mga user na maa-authenticate ay kailangang makagawa ng mga certificate, kung hindi man ay ang mga hakbang cert at buntong-hininga may makikita kang error.

iba pang mga opsyon

Bukod sa simpleng paraan na ito, may iba pang mga paraan para i-configure ang mga certificate at profile. Kaya, kung iba ang iyong trabaho, maaaring kailanganin mong umangkop. Ang pinakamahalagang bagay ay kailangan mo ng pagsasaayos .xcodebuild, na magtuturo sa mga kinakailangang file, at dapat na available ang keychain sa build computer para sa user sa ilalim ng pangalan kung saan tumatakbo ang runner. Para sa digital signature gumagamit kami ng fastlane, at kung may mga problema o gusto mong malaman pa, tingnan ang kanilang mga detalye dokumentasyon tungkol sa mga digital na lagda.

Sa halimbawang ito ginagamit ko ang diskarte cert at buntong-hininga, ngunit para sa tunay na paggamit ay malamang na mas angkop ito tumugma.

Inihahanda ang GitLab at fastlane

Inihahanda ang CI Runner

Matapos makolekta ang lahat ng data na ito, nagpapatuloy kami sa pagsasaayos ng GitLab runner sa MacOS device. Sa kasamaang palad, maaari ka lamang gumawa ng mga iOS app sa MacOS. Ngunit lahat ay maaaring magbago, at kung inaasahan mong pag-unlad sa lugar na ito, bantayan ang mga proyekto tulad ng xcbuild ΠΈ tanda, at ang aming panloob na gawain gitlab-ce#57576.

Ang pag-set up ng runner ay napaka-simple. Sundin ang kasalukuyang mga tagubilin para sa pag-set up ng GitLab Runner sa macOS.

Tandaan. Ang runner ay dapat gumamit ng executable program shell. Ito ay kinakailangan upang bumuo ng iOS sa macOS upang gumana nang direkta bilang isang user sa halip na sa pamamagitan ng mga lalagyan. Kung ikaw ay gumagamit shell, ginagawa ang pagbuo at pagsubok bilang user ng runner, nang direkta sa build host. Ito ay hindi kasing-secure ng mga lalagyan, kaya mas mahusay na mag-browse dokumentasyon ng kaligtasanpara wala kang makaligtaan.

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

Dapat na i-configure ang Apple Keychain sa host na ito na may access sa mga key na kailangang gawin ng Xcode. Ang pinakamadaling paraan upang subukan ito ay ang mag-log in bilang user na tatakbo sa build at subukang gawin ito nang manu-mano. Kung humingi ang system ng keychain access, piliin ang Always Allow for CI to work. Maaaring sulit na pumasok at obserbahan ang unang pares ng mga pipeline upang matiyak na hindi na nila hihilingin ang keychain. Ang problema ay hindi pinapadali ng Apple para sa amin ang paggamit ng Auto mode, ngunit kapag natuloy mo na ito, magiging maayos ang lahat.

fastlane init

Upang gumamit ng fastlane sa isang proyekto, tumakbo fastlane init. Sumunod ka lang mga tagubilin para sa pag-install at pagpapatakbo ng fastlane, lalo na sa seksyon tungkol sa Gemfile, dahil kailangan namin ng mabilis at predictable na paglulunsad sa pamamagitan ng isang automated CI pipeline.

Sa iyong direktoryo ng proyekto, patakbuhin ang mga command na ito:

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

hihingi ang fastlane ng pangunahing configuration at pagkatapos ay gagawa ng fastlane folder sa proyekto na may tatlong file:

1. fastlane/Appfile

Walang kumplikado dito. Siguraduhin lang na tama ang iyong Apple ID at App ID.

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

2. fastlane/Fastfile

Fastfile tumutukoy sa mga hakbang sa pagbuo. Gumagamit kami ng maraming built-in na feature ng fastlane, kaya malinaw din ang lahat dito. Gumagawa kami ng isang linya na tumatanggap ng mga sertipiko, nagsasagawa ng pagpupulong at ina-upload ito sa TestFlight. Maaari mong hatiin ang prosesong ito sa iba't ibang gawain kung kinakailangan. Lahat ng mga operasyong ito (get_certificates, get_provisioning_profile, gym ΠΈ upload_to_testflight) ay kasama na sa fastlane.

Aktibidad get_certificates ΠΈ get_provisioning_profile may kaugnayan sa diskarte sa pagpirma cert at buntong-hininga. Kung ikaw ay gumagamit tumugma o anuman, gumawa ng mga pagbabago.

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

Ito ay isang opsyonal na file, ngunit ginawa ko ito nang manu-mano upang baguhin ang default na direktoryo ng output at ilagay ang output sa kasalukuyang folder. Pinapasimple nito ang CI. Kung interesado, basahin ang tungkol sa gym at ang mga parameter nito sa dokumentasyon.

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

Natin .gitlab-ci.yml

Kaya, mayroon kaming CI runner para sa proyekto at handa kaming subukan ang pipeline. Tingnan natin kung ano ang mayroon tayo .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

ВсС ΠΎΡ‚Π»ΠΈΡ‡Π½ΠΎ! Itinakda namin ang format sa UTF-8 para sa fastlane kung kinakailangan, gumamit ng diskarte clone sa pagpapatupad ng programa shell, upang magkaroon tayo ng malinis na workspace para sa bawat pagpupulong, at tumawag lang flappybuild fastlane, tulad ng nakikita sa itaas. Bilang resulta, nakukuha namin ang assembly, lagda at deployment ng pinakabagong assembly sa TestFlight.

Nakukuha din namin ang artifact at i-save ito kasama ang pagpupulong. Pakitandaan na ang format .ipa ay isang nilagdaang ARM executable na hindi tumatakbo sa simulator. Kung gusto mo ng output para sa simulator, idagdag lang ang build target na gumagawa nito, at pagkatapos ay isama ito sa artifact path.

Iba pang mga variable ng kapaligiran

Mayroong ilang mga variable ng kapaligiran dito na nagpapagana sa lahat.

FASTLANE_APPLE_APPLICATION_SPECIFIC_PASSWORD ΠΈ FASTLANE_SESSION

Ang pagpapatotoo para sa fastlane ay kinakailangan upang mapatotohanan sa App Store at mag-upload sa TestFlight. Upang gawin ito, lumikha ng isang password para sa application na gagamitin sa CI. Mga Detalye dito.

Kung mayroon kang two-factor authentication, gumawa ng variable FASTLANE_SESSION (mga tagubilin doon).

FASTLANE_USER ΠΈ FASTLANE_PASSWORD

Na cert at buntong-hininga tinatawag na initialization profile at mga certificate kapag hiniling, kailangan mong itakda ang mga variable FASTLANE_USER ΠΈ FASTLANE_PASSWORD. Mga Detalye dito. Hindi ito kailangan kung gumagamit ka ng ibang paraan ng pagpirma.

Sa pagtatapos

Makikita mo kung paano gumagana ang lahat sa aking simpleng halimbawa.

Umaasa ako na ito ay nakatulong at nagbigay inspirasyon sa iyo na magtrabaho kasama ang mga build ng iOS sa isang proyekto ng GitLab. Eto pa isa Mga tip sa CI para sa fastlane, kung sakali. Baka gusto mong gamitin CI_BUILD_ID (para sa incremental build) sa awtomatikong dagdagan ang bersyon.

Ang isa pang cool na tampok ng fastlane ay awtomatikong mga screenshot para sa App Store, na napakadaling i-set up.

Sabihin sa amin sa mga komento ang tungkol sa iyong karanasan at ibahagi ang iyong mga ideya para sa pagpapabuti ng GitLab para sa pag-develop ng iOS app.

Pinagmulan: www.habr.com

Magdagdag ng komento