Per chi non sapesse cos’è un “Continuous Integration service” (per gli amici anche “CI”) sappiate che si tratta di un software il cui compito è quello di aiutare i team di sviluppatori a mettere in pratica la “Continuous Integration”. In breve recuperare dal sistema di versioning tutte le features scritte dai diversi programmatori del team, metterle insieme e creare la nuova build dell’applicazione da distribuire ai beta tester.

Questo significa che a differenza di avere un numero limitato di builds in cui sono presenti magari decine di nuove funzinonalità da testare, avremo molte più builds, ciascuna con un numero molto minore (teoricamente solo una) di nuove funzioni. Il vantaggio risultante è misurabile in termini di testabilità del prodotto perché in questo modo è facile risalire all’esatta versione del software in cui è stato introdotto un bug, il lavoro del tester è focalizzato su specifiche e circoscritte funzionalità e in generale tutto è più bello e organizzato 🙂

Tipicamente se utilizzate git e un workflow come git-flow (https://www.atlassian.com/git/tutorials/comparing-workflows/#!workflow-gitflow) siete già a buon punto, perche’ non vi resta che eseguire una build ogni volta che un feature-branch viene integrato nel vostro master-branch, in questo modo avrete una nuova versione dell’app per ciascuna nuova funzionalità.

Quando si parla di Continuous Integration service il primo nome che viene in mente è quello di Jenkins (http://jenkins-ci.org/) una tra le più diffuse piattaforme che assolve perfettamente a questo scopo. Jenkins è in grado di buildare anche progetti iOS a patto di installare e configurare l’apposito plugin (https://wiki.jenkins-ci.org/display/JENKINS/Xcode+Plugin) ed è anche free. L’unico lato negativo è che non è proprio semplice da configurare e probabilmente farà molto più di quello che realmente vi serve.

Altrimenti potete usare un servizio esterno come travis-ci https://travis-ci.org/ il problema in questo caso è che per utilizzare il servizio con i vostri progetti privati dovete pagare la cifra non indifferente di 129 dollari al mese.

Ovviamente esiste un’altra alternativa, cioè quella di farvi da voi uno script che faccia esattamente quello che vi serva… io c’ho provato ed ho deciso di condividere con voi il risultato nella speranza che possa essere utile a qualcuno.

Il codice sorgente è disponibile qui: https://github.com/ignazioc/xcodeci, il linguaggio utilizzato è Ruby, ho voluto infatti approfittare di questo progetto per approfondire un po’ questo linguaggio.

xcodeci verifica ciclicamente (default ogni 5 minuti) uno o più repository git e quando su uno specifico branch viene rilevato un nuovo commit, parte la procedura di build del repository ed esecuzione dei tests. Alla fine delle operazioni di build vengono generati automaticamente il file *.ipa e il file manifest.plist, che vengono poi salvati nella cartella “public”  di dropbox.

Quando tutti i progetti sono stati compilati viene generato un report html con le informazioni sul processo di build e il link per installare l’applicazione tramite OTA. Il report viene anch’esso salvato nella cartella pubblica di dropbox così che tutti coloro in possesso del link potranno installare le vostre beta.

Mentre lo script è attivo in console potrete vedere lo stato di esecuzione delle diverse operazioni:

mentre al termine dell’esecuzione il report si presenterà così:

Installazione e configurazione

La prima cosa da fare è quella di clonare il repository git https://github.com/ignazioc/xcodeci in una cartella del vostro mac. Potete farlo da terminale digitando:

git clone https://github.com/ignazioc/xcodeci

Il secondo step è quello di installare le dipendenze, il progetto richiede alcune gemme Ruby ed xctool. Potete installare le prime direttamente eseguendo da terminale (all’interno della cartella del progetto)

bundle install

Per installare xctool il metodo più semplice è quello di usare homebrew, il sistema di pacchetti per MacOS, se non l’avete già installato trovate le info qui: http://brew.sh/. Digitate quindi:

brew install xctool

Configurazione e avvio

Una volta installate le dipendenze potete lanciare lo script, se non vengono trovati file di configurazione lo script ve ne genera uno di esempio. All’interno della cartella del progetto digitiamo quindi:

./bin/xcodeci

Un messaggio vi informerà della creazione del file di esempio.

Il file di configurazione si chiama xcodeci.conf.yaml e lo trovate all’interno della cartella ~/.xcodeci

Si tratta di un file di testo con sintassi yaml (http://www.yaml.org/).

Il file di esempio mostra alcuni commenti in inglese, ma la configurazione è davvero molto semplice, questo è come potrebbe apparire un file corretto:

---
App_Config:
  :DROPBOX_FOLDER:    '/Users/ignazio/Dropbox/Public/'
  :DROPBOX_USER_ID:   '792862'
SampleApp1:
  :REPO_URL:         'git@github.com:ignazioc/sample_repo_1.git'
  :APP_NAME:         'SampleApp-1'
  :TARGET_BRANCH:    'master'
  :WORKSPACE:        'SampleApp 1.xcworkspace'
  :SCHEME:           'SampleApp 1'

La prima parte raccoglie due informazioni relative al vostro mac:

• :DROPBOX_FOLDER: non è altro che il path della vostra cartella public, verrà usata per salvare i file ipa e i manifest.
• :DROPBOX_USER_ID: È invece un numero che dropbox associa al vostro utente, lo script lo utilizza per generare “a mano” i link alla vostra cartella public.

Per trovare il vostro user_id provate a condividere qualsiasi file dentro la vostra cartella public, il link che otterrete è in questa forma:

https://dl.dropboxusercontent.com/u/792862/avatar_grumpy.png

quel numero dopo la ‘u’ è il vostro user_id.

Seguono poi uno o più sezioni relative ai progetti da monitorare:

• :REPO_URL: url del repository git.
• :APP_NAME: Viene usato per generare le sotto-cartelle dove salvare i flie ipa, non usare spazi nel nome.
• :TARGET_BRANCH: Branch da monitorare, solitamente è master.
• :WORKSPACE: Nome del workspace, non sono gestiti progetti senza workspace.
• :SCHEME: Lo schema da buildare

Quando avrete il vostro file di configurazione provate a ri-eseguire lo script, se tutto è ok lo script eseguirà un loop ogni 5 minuti in cui proverà a buildare tutti i progetti inseriti nel file di configurazione.

Alla fine di ciascuna iterazione verrà mostrato il link (sarà sempre lo stesso) dove trovare il report html:

Condividete il link con i vostri beta tester e rilassatevi 🙂

Alcune note sul progetto:

• Per la distribuzione adhoc dovrete comunque aggiungere i device sul sito apple e configurare il progetto in modo che usi il corretto provisioning, niente miracoli per quello purtroppo 🙂
• Lo script non supporta al momento progetti che non siano legati ad un workspace, in ogni caso vista la diffusione di cocoapods non credo sia una limitazione rilevante.
• Ogni critica e/o suggerimento è ben accetto, commentate qui oppure forkate il repository su github.
• Potete installare anche con un gem install xcodeci senza usare git e senza preoccuparvi di dove sia l’eseguibile, perché vi basta digitare xcodeci da commandline.

Alla prossima e buona programmazione a tutti!