Come GitLab con fastlane compila, firma e pubblica applicazioni iOS su App Store.
Recentemente abbiamo avuto con GitLab e . Qui vedremo come compilare e lanciare un'app iOS e pubblicarla su TestFlight. Guarda quanto è fantastico , prendo la build e ricevo l'aggiornamento della versione beta dell'applicazione sullo stesso iPad Pro in cui l'ho sviluppata.
Qui prenderemo , con cui ho registrato un video.
Due parole sulla configurazione dell'Apple Store
Avremo bisogno di un'app su App Store, di certificati di distribuzione e di un profilo di provisioning per mettere tutto insieme.
La parte più complicata qui è configurare i diritti di firma su App Store. Spero che voi possiate farlo da soli. Se siete principianti, vi indicherò la giusta direzione, ma qui non parleremo delle complessità della gestione dei certificati Apple, poiché sono in continua evoluzione. Questo post aiuterà a iniziare.
Le mie applicazioni
Occorre un'app su App Store Connect per avere un ID per la configurazione .xcodebuild. Il profilo e l'ID dell'applicazione combinano le build del codice, i prezzi e la disponibilità, oltre alla configurazione di TestFlight per la distribuzione delle app di test agli utenti. Non è necessario fare test pubblici; va bene anche quello privato se hai un piccolo gruppo, una configurazione semplice e non hai bisogno di permessi aggiuntivi da Apple.
Profilo di inizializzazione
Oltre alla configurazione dell'app, hai bisogno delle chiavi di distribuzione e sviluppo per iOS, create nella sezione Certificates, Identifiers & Profiles (Certificati, Identificatori e Profili) nella console Apple Developer. Tutti questi certificati possono essere combinati in un profilo di inizializzazione.
Gli utenti che devono effettuare l'autenticazione necessitano della possibilità di creare certificati, altrimenti nelle fasi visualizzerai un errore.
Altre opzioni
Oltre a questo metodo semplice, ci sono altri modi per configurare certificati e profili. Quindi, se stai lavorando in modo diverso, potresti dover adattarti. La cosa più importante è che avrai bisogno di una configurazione .xcodebuild, che indicherà i file necessari, e la coppia di chiavi deve essere disponibile sul computer di build per l'utente sotto il cui nome opera il runner. Per la firma digitale utilizziamo fastlane, e se ci sono problemi o vuoi saperne di più, consulta la loro dettagliata .
In questo esempio utilizzo un approccio , ma per un'applicazione reale probabilmente sarà più adatto .
Preparazione di GitLab e fastlane
Preparazione del CI Runner
Raccolte tutte queste informazioni, passiamo alla configurazione del GitLab Runner su un dispositivo MacOS. Sfortunatamente, è possibile sviluppare applicazioni iOS solo su MacOS. Ma tutto può cambiare, e se aspetti novità in questo campo, segui progetti come e , e il nostro compito interno .
Configurare il runner è molto semplice. Segui le attuali .
Nota. Il runner deve utilizzare un eseguibile shell. Questo è obbligatorio per compilare iOS in macOS, affinché funzioni direttamente come utente e non tramite container. Se stai usando shellla compilazione e il testing vengono eseguiti a nome dell'utente del runner, direttamente sull'host di compilazione. Non è così sicuro come i contenitori, quindi è meglio scorrere , per non perdere nulla.
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 startIl portachiavi Apple deve essere configurato su questo host con accesso alle chiavi necessarie per Xcode per la compilazione. Il modo più semplice per testarlo è accedere come utente che eseguirà la compilazione e provare a compilarla manualmente. Se il sistema richiede accesso al portachiavi, seleziona «Consenti sempre» affinché il CI funzioni. Potrebbe valere la pena accedere e osservare i primi paio di pipeline, per assicurarti che non richiedano più il portachiavi. Il problema è che Apple non facilita il lavoro con la modalità automatica, ma una volta che la imposti, andrà tutto bene.
fastlane init
Per utilizzare fastlane nel progetto, esegui fastlane init. Segui semplicemente , specialmente nella sezione su , poiché abbiamo bisogno di un avvio rapido e prevedibile tramite un pipeline CI automatizzato.
Nel catalogo del progetto, esegui questi comandi:
xcode-select --install
sudo gem install fastlane -NV
# In alternativa, usando Homebrew
# brew cask install fastlane
fastlane initfastlane richiederà una configurazione di base e poi creerà nella cartella del progetto la cartella fastlane con tre file:
1. fastlane/Appfile
Qui non c'è nulla di complicato. Controlla solo che l'Apple ID e l'ID dell'app siano stati inseriti correttamente.
app_identifier("com.vontrance.flappybird") # L'identificativo del bundle della tua app
apple_id("your-email@your-domain.com") # Il tuo indirizzo email Apple2. fastlane/Fastfile
Fastfile , definisce i passaggi di compilazione. Utilizziamo molte funzionalità integrate di fastlane, quindi anche qui tutto è chiaro. Creiamo una linea che ottiene i certificati, esegue la compilazione e la carica su TestFlight. Puoi dividere questo processo in diversi compiti, se necessario. Tutte queste operazioni (get_certificates, get_provisioning_profile, gym e upload_to_testflight) sono già incluse in fastlane.
Azioni get_certificates e get_provisioning_profile sono legate al metodo di firma . Se utilizzi o altro, apporta le modifiche necessarie.
default_platform(:ios)
platform :ios do
desc "Compila l'applicazione"
lane :flappybuild do
get_certificates
get_provisioning_profile
gym
upload_to_testflight
end
end3. fastlane/Gymfile
Questo file è facoltativo, ma l'ho creato manualmente per cambiare la cartella di output predefinita e posizionare i risultati nella cartella corrente. Questo semplifica il CI. Se sei interessato, leggi di gym e delle sue opzioni in .
https://docs.fastlane.tools/actions/gym/Il nostro .gitlab-ci.yml
Quindi, abbiamo un runner CI per il progetto e siamo pronti a testare il pipeline. Vediamo cosa abbiamo 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.ipaTutto perfetto! , usando la strategia clone con il programma eseguibile shell, in modo da avere un ambiente di lavoro pulito per ogni build, e chiamiamo semplicemente flappybuild fastlane, come mostrato sopra. Alla fine otteniamo una build, una firma e il deploy dell'ultima build in TestFlight.
Otteniamo anche un artefatto e lo salviamo con la build. Nota che il formato .ipa è un file eseguibile ARM firmato, che non può essere eseguito nell'emulatore. Se desideri l'output per l'emulatore, basta aggiungere un target di build che lo produce e poi includerlo nel percorso dell'artefatto.
Altre variabili ambientali
Ci sono un paio di variabili ambientali su cui tutto si basa.
FASTLANE_APPLE_APPLICATION_SPECIFIC_PASSWORD e FASTLANE_SESSION
Per l'autenticazione su App Store e il caricamento su TestFlight è necessaria l'autenticazione per fastlane. Crea una password per l'applicazione da utilizzare nel CI. Ulteriori dettagli .
Se hai l'autenticazione a due fattori, crea una variabile FASTLANE_SESSION (le istruzioni sono lì).
FASTLANE_USER e FASTLANE_PASSWORD
Per creare un file di esportazione del database di gestione sul server di origine: hai richiesto il profilo di inizializzazione e i certificati, è necessario configurare le variabili FASTLANE_USER e FASTLANE_PASSWORD. Ulteriori dettagli . Questo non è necessario se utilizzi un altro metodo di firma.
In conclusione
Puoi vedere come funziona tutto questo .
Spero che questo sia stato utile e ti abbia ispirato a lavorare con le build iOS nel progetto GitLab. Ecco altri per fastlane, nel caso decidessi di utilizzare CI_BUILD_ID (per build incrementali), per .
Un'altra funzionalità interessante di fastlane è per l'App Store, che è molto semplice da configurare.
Raccontaci nei commenti della tua esperienza e condividi idee per migliorare GitLab per lo sviluppo di applicazioni iOS.
Fonte: habr.com
