Share
In questa serie di tutorial esploreremo un processo raramente discusso (ma molto prezioso) di sviluppo di software che è deludentemente assente nel mondo iOS e mobile: Integrazione continua.
Nella parte 1, abbiamo discusso il concetto di Continuous Integration e come ci può aiutare nello sviluppo di software più velocemente. La seconda parte è passata attraverso l'installazione di Apache Tomcat, il server web che esegue il nostro software server CI. Nella parte 3, abbiamo installato e configurato Hudson per monitorare il nostro progetto e iniziare il processo di compilazione ogni volta che aggiorniamo il nostro repository di progetto. Nella parte 4, abbiamo scritto uno script di base che ha compilato il nostro progetto e generato un file IPA.
In questo momento abbiamo uno script di compilazione funzionante, ma c'è molto altro che possiamo fare! Questo tutorial è leggermente diverso dagli altri. Invece di farti fare una serie di passaggi, ci sarà una raccolta di utili aggiunte che potrai aggiungere al tuo script e, in base alle tue circostanze, puoi scegliere di aggiungerli o meno.
Gli script di Bash possono usare le funzioni proprio come gli altri linguaggi. Gli script di compilazione di grandi dimensioni possono essere piuttosto lunghi, quindi è importante organizzarli il più possibile. Le funzioni sono un ottimo modo per farlo.
Mettiamo tutto il nostro codice esistente in una funzione chiamata "buildApp". Apri lo script e inserisci il seguente codice:
function buildApp #existing code goes here
Per chiamare la nostra funzione "buildApp", basta inserire la seguente dichiarazione di funzione:
BUILDAPP
Man mano che aggiungi più funzionalità allo script, puoi inserirle in funzioni con nomi diversi come "distributeApp" o "signApp".
Uno dei servizi più popolari che gli sviluppatori usano per testare le loro app è TestFlight. TestFlight è un ottimo servizio (gratuito!) Online che consente agli sviluppatori di caricare facilmente il proprio IPA ad-hoc e TestFlight si prende cura della distribuzione.
TestFlight fornisce un'API di caricamento che possiamo chiamare dal nostro script bash. Ciò significa che ogni volta che completiamo una nuova build, possiamo caricarla immediatamente per testare il volo e informare i nostri tester che è disponibile una nuova build.
Innanzitutto, assicurati di avere un account e ottieni il token dell'API e il token del team. Fatto ciò, aggiungi l'API e la chiave del team all'inizio del tuo script come variabili.
In secondo luogo, dobbiamo preparare il file * .dysm per il caricamento. Se non ricordi cosa sia il file * .dysm, fai riferimento all'articolo 4 per un aggiornamento. Il file * .dysm deve essere compresso prima di poter essere caricato su TestFlight o Apple, quindi è una buona idea farlo come parte del processo di compilazione.
Aggiungi il seguente codice dopo il comando "xcodebuild":
#zip file DYSM per la distribuzione cd "$ build_location / sym.root / $ configuration- $ sdk /" || die "no tale directory" rm -f "$ appname.app.dSYM.zip" zip -r "$ appname.app.dSYM.zip" "$ appname.app.dSYM"
Il codice sopra riportato semplicemente cambia directory nella posizione del file * .dysm e rimuove tutti i file zip che possono essere esistiti prima. Successivamente, crea un ZIP del file * .dysm.
Dopo che questo è stato aggiunto, aggiungi la seguente funzione al tuo script di build:
function deployToTestFlight / usr / bin / curl "http://testflightapp.com/api/builds.json" \ -F file = @ "$ build_location / $ appname.ipa" \ -F dsym = @ "$ build_location / sym .root / $ configuration- $ sdk / $ appname.app.dSYM.zip "\ -F api_token =" $ TESTFLIGHT_APIKEY "\ -F team_token =" $ TESTFLIGHT_TEAM "\ -F notes =" $ nome app caricato tramite l'API di caricamento testflight "\ -F notify =" False "
Ora, se hai bisogno di eseguire la distribuzione su TestFlight, tutto ciò che devi fare è chiamare la funzione "deployToTestFlight" dopo che una build è stata generata.
Per informazioni complete sull'API di caricamento di TestFlight, consulta https://testflightapp.com/api/doc/.
A volte, potremmo aver bisogno di modificare o leggere valori dal file * .plist. Ad esempio, potremmo voler memorizzare build per ogni versione dell'app. Possiamo leggere la versione dell'app dal file PLIST e memorizzarla in una cartella appropriata. Potremmo anche voler modificare l'icona utilizzata per una build specifica o, a volte, persino l'identificatore del bundle.
Per impostare l'ID bundle (cioè sovrascrivere il valore originale), il comando è:
/ usr / libexec / PlistBuddy -c "Set: CFBundleIdentifier $ bundle_id" Info.plist
Come puoi vedere dall'immagine qui sopra, "CFBundleIdentifier" è la chiave per il valore dell'ID bundle, quindi dobbiamo semplicemente "impostarlo" come $ bundle_id il valore è.
Se vogliamo leggere un valore da PLIST e impostarlo come variabile nel nostro script, è un po 'più complicato. Dobbiamo fare un po 'di trucco di bash:
app_version_number = $ (/ usr / libexec / PlistBuddy -c "Stampa: CFBundleVersion" Info.plist)
Il codice sopra riportato tra parentesi stampa semplicemente il valore di "CFBundleVersion" e lo script di bash acquisisce quel valore come variabile e lo assegna alla variabile "numero_versione_app".
In Xcode puoi usare diverse configurazioni per il tuo progetto. Ogni configurazione può utilizzare diverse impostazioni di compilazione, opzioni di firma del codice, anche compilare in modo diverso in base alle macro del pre-processore. Sebbene la creazione di nuove configurazioni, la modifica delle impostazioni di generazione e l'aggiunta di macro pre-processore vadano oltre lo scopo di questo tutorial, posso mostrarti come costruirle.
La configurazione di default quando si crea è "Release", ma può essere impostata con un flag speciale quando si chiama il comando "xcodebuild".
In questo esempio, abbiamo una configurazione chiamata "Test". Per creare questa configurazione, adattiamo semplicemente il nostro script di build in base a quanto segue:
configuration = "Test" xcodebuild -target "$ appname" -configurazione "$ configuration" OBJROOT = "$ build_location / $ app_version / $ configuration / obj.root" SYMROOT = "$ build_location / $ app_version / $ configuration / sym.root"
Qui stiamo costruendo il nostro progetto Xcode basato su una configurazione specifica e inserendolo nella sua stessa cartella insieme al proprio numero di versione (che possiamo ottenere guardando il file info.plist, vedere l'aggiunta 3).
Se lavori per un'organizzazione di dimensioni medio-grandi, è probabile che utilizzerai più di un certificato di sviluppo / distribuzione per firmare le tue app. Se non hai il controllo sulla creazione di questi certificati, c'è anche la possibilità che tutti i certificati abbiano le tue aziende nominate da qualche parte.
Questo è un problema perché il portachiavi non consente la firma di un certificato quando è "ambiguo". Fortunatamente, possiamo usare il comando "sicurezza" per aggiungere ed eliminare certificati durante il nostro processo di compilazione.
Innanzitutto, è necessario esportare i certificati pertinenti e le loro chiavi private dal portachiavi e aggiungerli alla directory degli script. Quando esporti il certificato e la chiave, il portachiavi ti chiederà di inserire una passphrase. Immettere una passphrase e quindi salvare il file * .p12 nella directory scripts del proprio repository. Imposta il file * .p12 come nome di variabile nel tuo script.
In secondo luogo, eliminare tutti i certificati sul server di build che potrebbero entrare in conflitto con il certificato da utilizzare.
Infine, aggiungi la seguente riga per importare il certificato:
importazione di sicurezza "$ WORKSPACE / Scripts / $ CERTIFICATE_FILE.p12" -P "$ password" -A -k ~ / Libreria / Portachiavi / login.keychain
Questa linea importa il designato * .p12 nel portachiavi di login usando la password "$ password".
Quando hai finito la build, rimuovila dal portachiavi in questo modo:
security delete-certificate -c "$ certificate"
Usando il metodo sopra puoi costruire la tua app più volte usando più certificati che altrimenti sarebbero stati ambigui l'uno con l'altro.
Mentre queste sono utili aggiunte a qualsiasi script di costruzione, ci saranno sempre modi specifici per far sì che funzioni meglio per te. Ho fatto del mio meglio per insegnarti le basi e fornirti una base sufficiente per avere una solida base su cui sperimentare e sviluppare ulteriormente.
Uno script contenente tutti i passaggi sopra descritti può essere trovato su https://gist.github.com/1404526
Spero che questa serie di tutorial ti sia piaciuta e che tu sia in grado di implementare CI e processi automatizzati nel tuo flusso di lavoro di sviluppo. Possiate avere molte luci blu per la costruzione! :)
Accentsconagua