Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
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.
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
I campioni di contenuti e codice in questa pagina sono soggetti alle licenze descritte nella Licenza per i contenuti. Java e OpenJDK sono marchi o marchi registrati di Oracle e/o delle sue società consociate.
Ultimo aggiornamento 2025-07-27 UTC.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Mancano le informazioni di cui ho bisogno","missingTheInformationINeed","thumb-down"],["Troppo complicato/troppi passaggi","tooComplicatedTooManySteps","thumb-down"],["Obsoleti","outOfDate","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Problema relativo a esempi/codice","samplesCodeIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 2025-07-27 UTC."],[],[],null,["# CI features\n\nThe following are some features that you can find in most CI systems.\n\nEnvironment\n-----------\n\nIt's important to choose and understand the hardware and software environment in\nwhich the system executes the workflow. Important considerations for Android\napplications are:\n\n- **Platform**: Linux, Mac, Windows, and their versions.\n- **Available memory**: Building apps and running emulators can use a lot of RAM and it's often necessary to tweak parameters such as the JVM's heap size to avoid out-of-memory errors.\n- **Preinstalled software**: CI systems usually provide images with a large collection of tools already available, such as the Java Development Kit (JDK), the Android Software Development Kit (SDK), build tools, platforms and emulators.\n- **Runner architecture and instruction set**: ARM, x86. This is important when using emulators.\n- **Environment variables** : Some are set by the CI system (for example: `ANDROID_HOME`) and you can set your own to, for example, avoid hardcoding credentials in your workflow.\n\nThere are many other aspects you should consider, such as the number of cores\navailable, and whether virtualization is enabled to run emulators.\n\nLogs and reports\n----------------\n\nWhen a step fails, the CI system notifies you and usually doesn't let you merge\nthe change. To find out what has gone wrong, look for errors in the logs.\n\nAdditionally, building and testing generates reports that are usually stored as\nartifacts of that particular build. Depending on the CI system, you can use\nplugins to visualize the results of those reports.\n\nCache and CI run times\n----------------------\n\nCI systems use a build cache to speed up the process. In its simplest form, they\nsave all the Gradle cache files after a successful build and restore them before\na new one. This relies on [Gradle's build cache](https://docs.gradle.org/current/userguide/build_cache.html) feature and should be\nenabled in your project.\n| **Note:** take into account the time that it takes for the cache to download as, if the cache becomes too big and it contains more than is necessary, it could be detrimental to the overall build time.\n\nSome ways to improve run times and reliability include:\n\n- **Modules**: Detecting which modules are affected by a change and only building and testing those.\n- **Skip caches**: If the build includes scripts that a developer has modified, ignore the build caches. It's safer to build from scratch.\n- **Shard tests**: Especially instrumented tests, it can be helpful to shard tests across multiple devices. This is supported by the Android runner, Gradle Managed Devices and Firebase Test Lab.\n- **Shard builds**: You can shard the build across multiple server instances.\n- **Remote cache** : You can also use [Gradle's remote cache](https://docs.gradle.org/current/userguide/build_cache.html).\n\nRetry failed tests\n------------------\n\nFlakiness refers to tests or tools that fail intermittently. You should always\ntry to find and fix the problems that generate flaky builds and tests, but some\nof them are difficult to reproduce, especially when running instrumented tests.\nA common strategy is to retry test runs whenever they fail, up to a maximum\nnumber of retries.\n\nThere is no single way to configure retries, as they can occur at multiple\nlevels. The following table outlines the action you might take in response to a\nflaky test failure:\n\n| Failure | Action |\n|--------------------------------------------------------------|-----------------------|\n| Emulator was unresponsive for a second, triggering a timeout | Rerun the failed test |\n| Emulator failed to boot | Rerun the whole task |\n| There was a connection error during the code checkout phase | Restart the workflow |\n\nIt's important to log and keep track of which parts of the system are flaky and\ninvest in keeping CI reliable and fast, only relying on retries"]]
