Di seguito sono riportate alcune funzionalità disponibili nella maggior parte dei sistemi CI.
Ambiente
È importante scegliere e comprendere l'ambiente hardware e software in cui il sistema esegue il flusso di lavoro. Considerazioni importanti per le applicazioni Android sono:
- Piattaforma: Linux, Mac, Windows e relative versioni.
- Memoria disponibile: la creazione di app e gli emulatori in esecuzione possono utilizzare molta RAM ed è spesso necessario modificare parametri come la dimensione heap della JVM per evitare errori di esaurimento della memoria.
- Software preinstallato: i sistemi CI di solito forniscono immagini con un'ampia raccolta di strumenti già disponibili, come il Java Development Kit (JDK), l'Android Software Development Kit (SDK), gli strumenti di build, le piattaforme e gli emulatori.
- Architettura dell'esecuzione e set di istruzioni: ARM, x86. Questo è importante quando si utilizzano emulatori.
- Variabili di ambiente: alcune sono impostate dal sistema CI (ad esempio:
ANDROID_HOME) ed è possibile impostarle personalizzate, ad esempio per evitare di impostare come hardcoded le credenziali nel flusso di lavoro.
Ci sono molti altri aspetti da considerare, come il numero di core disponibili e l'abilitazione della virtualizzazione per eseguire gli emulatori.
Log e report
Quando un passaggio non va a buon fine, il sistema CI ti avvisa e di solito non ti consente di unire la modifica. Per scoprire che cosa non ha funzionato, cerca gli errori nei log.
Inoltre, la creazione e i test generano report che vengono solitamente archiviati come artefatti di quella determinata build. A seconda del sistema CI, è possibile utilizzare i plug-in per visualizzare i risultati di questi report.
Tempi di esecuzione di cache e CI
I sistemi CI utilizzano una cache di build per accelerare il processo. Nella sua forma più semplice, salvano tutti i file della cache di Gradle dopo una build riuscita e li ripristinano prima di una nuova. Si basa sulla funzionalità Cache di build di Gradle e dovrebbe essere abilitato nel tuo progetto.
Ecco alcuni modi per migliorare i tempi di esecuzione e l'affidabilità:
- Moduli: consente di rilevare quali moduli sono interessati da una modifica e solo di creare e testare tali moduli.
- Ignora cache: se la build include script modificati da uno sviluppatore, ignora le cache. È più sicuro costruire da zero.
- Shard test: in particolare i test strumentati, possono essere utili per eseguire test dello shard su più dispositivi. Questa funzionalità è supportata da Android runner, Gradle Managed Devices e da Firebase Test Lab.
- Creazioni shard: puoi partizionare la build su più istanze server.
- Cache remota: puoi anche utilizzare la cache remota di Gradle.
Riprova i test non riusciti
Per imperfezioni si intendono test o strumenti che non funzionano a intermittenza. Dovresti sempre provare a individuare e risolvere i problemi che generano build e test instabili, ma alcuni sono difficili da riprodurre, soprattutto durante l'esecuzione di test con strumentazione. Una strategia comune consiste nel ritentare le esecuzioni di test ogni volta che non hanno esito positivo, fino a un numero massimo di nuovi tentativi.
Non esiste un unico modo per configurare i nuovi tentativi, poiché possono verificarsi a più livelli. La seguente tabella illustra l'azione che potresti intraprendere in risposta a un errore di test instabile:
Errore |
Azione |
|---|---|
L'emulatore non risponde per un secondo e attiva un timeout |
Esegui di nuovo il test non riuscito |
Avvio dell'emulatore non riuscito |
Esegui di nuovo l'intera attività |
Si è verificato un errore di connessione durante la fase di pagamento del codice |
Riavvia il flusso di lavoro |
È importante registrare e tenere traccia di quali parti del sistema sono instabili e investire per mantenere la CI affidabile e veloce, facendo affidamento solo sui nuovi tentativi