Uso di TeamCity con Xamarin
Questa guida illustra i passaggi relativi all'uso di TeamCity per compilare le applicazioni per dispositivi mobili e quindi inviarle al test di App Center.
Come illustrato nella guida Introduzione all'integrazione continua, l'integrazione continua (CI) è una pratica utile quando si sviluppano applicazioni per dispositivi mobili di qualità. Sono disponibili molte opzioni valide per il software server di integrazione continua; questa guida si concentrerà su TeamCity di JetBrains.
Esistono diverse permutazioni di un'installazione di TeamCity. L'elenco seguente descrive alcune di queste permutazioni:
Servizio Windows: in questo scenario, TeamCity viene avviato all'avvio di Windows come servizio Windows. Deve essere associato a un host di compilazione Mac per compilare tutte le applicazioni iOS.
Avviare il daemon in OS X : concettualmente, questo comportamento è simile all'esecuzione di un servizio Windows descritto nel passaggio precedente. Per impostazione predefinita, le compilazioni verranno eseguite con l'account radice.
Account utente in OS X : è possibile eseguire TeamCity con un account utente che viene avviato ogni volta che l'utente accede.
Degli scenari precedenti, l'esecuzione di TeamCity con un account utente in OS X è il più semplice e più semplice da configurare.
Sono necessari diversi passaggi per la configurazione di TeamCity:
Installazione di TeamCity : l'installazione di TeamCity non è descritta in questa guida. Questa guida presuppone che TeamCity sia installato e in esecuzione con un account utente. Le istruzioni sull'installazione di TeamCity sono disponibili nella documentazione di TeamCity 8 di JetBrains.
Preparazione del server di compilazione: questo passaggio prevede l'installazione del software, degli strumenti e dei certificati necessari per creare applicazioni per dispositivi mobili e prepararle per la distribuzione.
Creazione di uno script di compilazione: questo passaggio non è strettamente necessario, ma uno script di compilazione è utile per la creazione automatica di applicazioni. L'uso di uno script di compilazione consente di risolvere i problemi di compilazione che possono verificarsi e offre un modo coerente e ripetibile per creare i file binari per la distribuzione, anche se l'integrazione continua non è praticata.
Creazione di un progetto TeamCity: una volta completati i tre passaggi precedenti, è necessario creare un progetto TeamCity che conterrà tutti i metadati necessari per recuperare il codice sorgente, compilare i progetti e inviare i test al test di App Center.
È necessaria l'esperienza con il test di App Center.
È necessaria la familiarità con TeamCity 8.1. L'installazione di TeamCity esula dall'ambito di questo documento. Si presuppone che TeamCity sia installato in OS X Mavericks ed è in esecuzione con un account utente normale e non con l'account radice.
Il server di compilazione deve essere un computer autonomo, che esegue OS X, dedicato all'integrazione continua. Idealmente, il server di compilazione non sarà responsabile di altri ruoli, ad esempio un server di database, un server Web o una workstation per sviluppatori.
Importante
Questa guida non tratta un'installazione "headless" di Xamarin.
Affinché i test vengano inviati a Xamarin Test Cloud, il computer che invia i test deve essere in grado di comunicare con i server di test cloud. I firewall devono essere configurati per consentire il traffico di rete da e verso i server situati in testcloud.xamarin.com sulle porte 80 e 443. Questo endpoint è gestito da DNS e l'indirizzo IP è soggetto a modifiche.
In alcune situazioni, un test (o un dispositivo che esegue il test) deve comunicare con i server Web protetti da un firewall. In questo scenario il firewall deve essere configurato per consentire il traffico dagli indirizzi IP seguenti:
- 195.249.159.238
- 195.249.159.239
Un passaggio fondamentale nella configurazione di un server di compilazione consiste nell'installare tutti gli strumenti, il software e i certificati necessari per compilare le applicazioni per dispositivi mobili. È importante che il server di compilazione possa compilare la soluzione per dispositivi mobili ed eseguire tutti i test. Per ridurre al minimo i problemi di configurazione, il software e gli strumenti devono essere installati nello stesso account utente che ospita TeamCity. L'elenco seguente illustra in dettaglio gli elementi necessari:
- Visual Studio per Mac: include Xamarin.iOS e Xamarin.Android.
- Accedere all'archivio componenti Xamarin: questo passaggio è facoltativo e obbligatorio solo se l'applicazione usa Componenti dall'archivio componenti Xamarin. A questo punto, l'accesso proattivo all'archivio componenti impedirà eventuali problemi quando una compilazione di TeamCity tenta di compilare l'applicazione.
- Xcode: Xcode è necessario per compilare e firmare applicazioni iOS.
- Strumenti da riga di comando Xcode: questo è descritto nel passaggio 1 della sezione Installazione della guida Aggiornamento di Ruby con rbenv .
- Firma di profili di identità e provisioning : importare i certificati e il profilo di provisioning tramite XCode. Per altri dettagli, vedere la guida di Apple sull'esportazione delle identità di firma e dei profili di provisioning.
- Archivi chiavi Android: copiare gli archivi chiavi Android necessari in una directory a cui l'utente di TeamCity può accedere, ad esempio
~/Documents/keystores/MyAndroidApp1
. - Calabash : si tratta di un passaggio facoltativo se l'applicazione ha test scritti usando Calabash. Per altre informazioni, vedere la guida all'installazione di Calabash in OS X Mavericks e la guida relativa all'aggiornamento di Ruby con rbenv .
Il diagramma seguente illustra tutti questi componenti:
Una volta installato tutto il software, accedere all'account utente e verificare che tutto il software sia installato e funzionante correttamente. Questo dovrebbe comportare la compilazione della soluzione e l'invio dell'applicazione al test di App Center. Questa operazione può essere semplificata eseguendo lo script di compilazione, come descritto nella sezione successiva.
Anche se è possibile che TeamCity gestisca tutti gli aspetti della compilazione e dell'invio di applicazioni mobili a App Center Test da solo; è consigliabile creare uno script di compilazione. Uno script di compilazione offre i vantaggi seguenti:
- Documentazione: uno script di compilazione funge da forma di documentazione su come viene compilato il software. In questo modo vengono rimosse alcune delle "magic" associate alla distribuzione dell'applicazione e consentono agli sviluppatori di concentrarsi sulle funzionalità.
- Ripetibilità : uno script di compilazione garantisce che ogni volta che l'applicazione viene compilata e distribuita, avviene nello stesso modo, indipendentemente da chi o cosa fa il lavoro. Questa coerenza ripetibile rimuove eventuali problemi o errori che potrebbero essere visualizzati a causa di un errore di compilazione o di errore umano eseguito in modo non corretto.
- Controllo delle versioni: uno script di compilazione può essere incluso nel sistema di controllo del codice sorgente. Ciò significa che le modifiche apportate allo script di compilazione possono essere rilevate, monitorate e corrette se vengono rilevati errori o imprecisioni.
- Preparare l'ambiente : uno script di compilazione può includere la logica per installare eventuali dipendenze di terze parti necessarie. In questo modo si garantisce che le applicazioni vengano compilate con i componenti appropriati.
Lo script di compilazione può essere semplice come un file di PowerShell (in Windows) o uno script bash (in OS X). Quando si crea lo script di compilazione, sono disponibili diverse opzioni per i linguaggi di scripting:
Rake: si tratta di un linguaggio specifico del dominio (DSL) per la compilazione di progetti basati su Ruby. Rake ha il vantaggio della popolarità e di un ricco ecosistema di librerie.
psake : si tratta di una libreria di Windows PowerShell per la creazione di software
FAKE : si tratta di un linguaggio DSL basato su F# che consente di usare librerie .NET esistenti, se necessario.
Il linguaggio di scripting usato dipende dalle preferenze e dai requisiti.
Nota
È possibile usare un sistema di compilazione basato su XML, ad esempio MSBuild o NAnt, ma questi non dispongono dell'espressività e della gestibilità di un dsl dedicato alla creazione di software.
Il processo di compilazione e test del software richiede informazioni che devono essere mantenute segrete. La creazione di un APK può richiedere una password per l'archivio chiavi e/o l'alias della chiave nell'archivio chiavi. Analogamente, Il test di App Center richiede una chiave API univoca per uno sviluppatore. Questi tipi di valori non devono essere hardcoded nello script di compilazione. Devono invece essere passati come variabili allo script di compilazione.
Meno sensibili sono valori come l'ID dispositivo iOS o l'ID dispositivo Android che identificano i dispositivi che devono essere usati da App Center per le esecuzioni di test. Questi non sono valori che devono essere protetti, ma possono passare dalla compilazione alla compilazione.
L'archiviazione di questi tipi di variabili all'esterno dello script di compilazione semplifica anche la condivisione dello script di compilazione all'interno di un'organizzazione, ad esempio con gli sviluppatori. Gli sviluppatori possono usare lo stesso script del server di compilazione, ma possono usare i propri archivi chiavi e chiavi API.
Esistono due opzioni possibili per l'archiviazione di questi valori sensibili:
Un file di configurazione: per proteggere la chiave API, questo valore non deve essere archiviato nel controllo della versione. Il file può essere creato per ogni computer. La modalità di lettura dei valori da questo file dipende dal linguaggio di scripting usato.
Variabili di ambiente: possono essere facilmente impostate in base al computer e sono indipendenti dal linguaggio di scripting sottostante.
Ci sono vantaggi e svantaggi per ognuna di queste scelte. TeamCity funziona perfettamente con le variabili di ambiente, quindi questa guida consiglia questa tecnica durante la creazione di script di compilazione.
Lo script di compilazione deve eseguire i passaggi seguenti:
Compilare l'applicazione : include la firma dell'applicazione con il profilo di provisioning corretto.
Inviare l'applicazione a Xamarin Test Cloud : include firma e zip che allineano l'APK con l'archivio chiavi appropriato.
Questi due passaggi verranno illustrati in modo più dettagliato di seguito.
La riga di comando seguente per specificare una build di rilascio della soluzione SOLUTION_FILE.sln per i Telefono. Il percorso dell'IPA può essere impostato specificando la proprietà nella IpaPackageDir
riga di comando:
Nel Mac, usando xbuild:
xbuild /p:Configuration="Release" \ /p:Platform="iPhone" \ /p:IpaPackageDir="$HOME/Builds" \ /t:Build MyProject.sln
Il comando xbuild si trova in genere nella directory /Library/Frameworks/Mono.framework/Commands.
In Windows, usando msbuild:
msbuild /p:Configuration="Release" /p:Platform="iPhone" /p:IpaPackageDir="%USERPROFILE%\Builds" /p:ServerAddress="192.168.1.3" /p:ServerUser="macuser" /t:Build MyProject.sln
msbuild non espande $( )
automaticamente le espressioni passate dalla riga di comando. Per questo motivo è consigliabile usare un percorso completo quando si imposta nella IpaPackageDir
riga di comando.
Per altre informazioni sulla proprietà, vedere le note sulla IpaPackageDir
versione per iOS 9.8.
Per compilare un'applicazione Android, usare xbuild (o msbuild in Windows):
/Library/Frameworks/Mono.framework/Commands/xbuild /t:SignAndroidPackage /p:Configuration=Release /path/to/android.csproj
La compilazione dell'applicazione xbuild Android usa il progetto, mentre l'applicazione iOS xbuild usa la soluzione.
Gli oggetti UITest vengono inviati usando l'interfaccia della riga di comando di App Center, come illustrato nel frammento di codice seguente:
appcenter test run uitest --app <TEAM-NAME/APP-NAME> --devices <DEVICE_SET> --token <API_KEY> --app-path <appname.APK-or-appname.IPA> --merge-nunit-xml report.xml --build-dir pathToUITestBuildDir
Quando il test viene eseguito, i risultati del test verranno restituiti sotto forma di file XML in stile NUnit denominato report.xml. TeamCity visualizzerà le informazioni nel log di compilazione.
Per altre informazioni su come inviare UITests ad App Center, vedere Preparazione di app Xamarin.Android o Preparazione di app Xamarin.iOS.
I test calabash vengono inviati usando l'interfaccia della riga di comando di App Center, come illustrato nel frammento di codice seguente:
appcenter test run calabash --app <TEAM-NAME/APP-NAME> --devices <DEVICE_SET> --token <API_KEY> --app-path <appname.APK-or-appname.IPA> --project-dir pathToProjectDir
Per inviare un'applicazione Android al test di App Center, è necessario prima ricompilare il server di test APK usando calabash-android:
$ calabash-android build </path/to/signed/APK>
$ appcenter test run calabash --app <TEAM-NAME/APP-NAME> --devices <DEVICE_SET> --token <API_KEY> --app-path <appname.APK> --project-dir pathToProjectDir
Per altre informazioni sull'invio di test di Calabash, vedere la guida di Xamarin sull'invio di test calabash al cloud di test.
Dopo aver installato TeamCity e aver Visual Studio per Mac possibile compilare il progetto, è possibile creare un progetto in TeamCity per compilare il progetto e inviarlo ad App Center.
Avviato accedendo a TeamCity tramite il Web browser. Passare al progetto radice:
Sotto il progetto radice creare un nuovo sottoprogetto:
Dopo aver creato il sottoprogetto, aggiungere una nuova configurazione di compilazione:
Collegare un progetto VCS alla configurazione di compilazione. Questa operazione viene eseguita tramite la schermata Impostazioni controllo della versione:
Se non è stato creato alcun progetto VCS, è possibile crearne uno dalla pagina Nuova radice VCS illustrata di seguito:
Dopo aver collegato la radice VCS, TeamCity estrae il progetto e prova a rilevare automaticamente i passaggi di compilazione. Se si ha familiarità con TeamCity, è possibile selezionare uno dei passaggi di compilazione rilevati. Per il momento è possibile ignorare i passaggi di compilazione rilevati.
Configurare quindi un trigger di compilazione. In questo modo verrà accodato una compilazione quando vengono soddisfatte determinate condizioni, ad esempio quando un utente esegue il commit del codice nel repository. Lo screenshot seguente mostra come aggiungere un trigger di compilazione:
Un esempio di configurazione di un trigger di compilazione può essere visualizzato nello screenshot seguente:
La sezione precedente, Parametrizzazione dello script di compilazione, suggerisce di archiviare alcuni valori come variabili di ambiente. Queste variabili possono essere aggiunte alla configurazione della compilazione tramite la schermata Parametri. Aggiungere le variabili per la chiave API di App Center, l'ID dispositivo iOS e l'ID dispositivo Android, come illustrato nello screenshot seguente:
Il passaggio finale consiste nell'aggiungere un passaggio di compilazione che richiamerà lo script di compilazione per compilare l'applicazione e accodare l'applicazione al test di App Center. Lo screenshot seguente è un esempio di passaggio di compilazione che usa un Rakefile per compilare un'applicazione:
A questo punto, la configurazione della compilazione è stata completata. È consigliabile attivare una compilazione per verificare che il progetto sia configurato correttamente. Un buon modo per eseguire questa operazione consiste nel eseguire il commit di una piccola modifica non significativa nel repository. TeamCity deve rilevare il commit e avviare una compilazione.
Al termine della compilazione, esaminare il log di compilazione e verificare se sono presenti problemi o avvisi con la compilazione che richiedono attenzione.
Questa guida ha illustrato come usare TeamCity per compilare applicazioni Xamarin Mobile e quindi inviarle al test di App Center. È stato illustrato come creare uno script di compilazione per automatizzare il processo di compilazione. Lo script di compilazione si occupa della compilazione dell'applicazione, dell'invio al test di App Center e dell'attesa dei risultati.
È stato quindi illustrato come creare un progetto in TeamCity che accoderà una compilazione ogni volta che uno sviluppatore esegue il commit del codice e chiamerà lo script di compilazione.