Voici quelques fonctionnalités disponibles dans la plupart des systèmes CI.
Environnement
Il est important de choisir et de comprendre l'environnement matériel et logiciel dans lequel le système exécute le workflow. Voici quelques points importants à prendre en compte pour les applications Android:
- Plate-forme: Linux, Mac, Windows et leurs versions.
- Mémoire disponible: la création d'applications et l'exécution d'émulateurs peuvent utiliser une grande quantité de RAM. De plus, il est souvent nécessaire de modifier des paramètres tels que la taille du tas de mémoire de la JVM pour éviter les erreurs de mémoire insuffisante.
- Logiciels préinstallés: les systèmes CI fournissent généralement des images avec un grand nombre d'outils déjà disponibles, tels que le kit de développement Java (JDK), le kit de développement logiciel (SDK) Android, des outils de compilation, des plates-formes et des émulateurs.
- Architecture de l'exécuteur et ensemble d'instructions: ARM, x86. C'est important lorsque vous utilisez des émulateurs.
- Variables d'environnement : certaines sont définies par le système CI (par exemple,
ANDROID_HOME
). Vous pouvez les définir pour éviter de coder en dur les identifiants dans votre workflow, par exemple.
Vous devez prendre en compte de nombreux autres aspects, tels que le nombre de cœurs disponibles et si la virtualisation est activée pour exécuter des émulateurs.
Journaux et rapports
Lorsqu'une étape échoue, le système d'intégration continue vous en informe et ne vous permet généralement pas de fusionner la modification. Pour identifier la cause du problème, recherchez les erreurs dans les journaux.
De plus, la compilation et les tests génèrent des rapports qui sont généralement stockés en tant qu'artefacts de cette version particulière. Selon le système d'intégration continue (CI), vous pouvez utiliser des plug-ins pour visualiser les résultats de ces rapports.
Temps d'exécution du cache et de la CI
Les systèmes CI utilisent un cache de build pour accélérer le processus. Dans leur forme la plus simple, ils enregistrent tous les fichiers de cache Gradle après une compilation réussie et les restaurent avant une nouvelle. Cette fonctionnalité repose sur la fonctionnalité de cache de build de Gradle et doit être activée dans votre projet.
Voici quelques moyens d'améliorer les temps d'exécution et la fiabilité:
- Modules: détecter les modules affectés par une modification, et uniquement les créer et les tester.
- Ignorer les caches: si la compilation inclut des scripts modifiés par un développeur, ignorez les caches de compilation. Il est plus sûr de partir de zéro.
- Tests segmentés: il peut être utile de segmenter les tests sur plusieurs appareils, en particulier les tests d'instrumentation. Cette fonctionnalité est compatible avec l'exécuteur Android, les appareils gérés par Gradle et Firebase Test Lab.
- Partitions: vous pouvez segmenter la compilation sur plusieurs instances de serveur.
- Cache distant: vous pouvez également utiliser le cache distant de Gradle.
Relancer les tests ayant échoué
Les failles désignent des tests ou des outils qui échouent par intermittence. Vous devez toujours essayer d'identifier et de résoudre les problèmes qui génèrent des builds et des tests irréguliers, mais certains d'entre eux sont difficiles à reproduire, en particulier lorsque vous exécutez des tests d'instrumentation. Une stratégie courante consiste à relancer les exécutions de test chaque fois qu'elles échouent, dans la limite du nombre maximal de tentatives.
Il n'existe pas une seule façon de configurer les nouvelles tentatives, car elles peuvent se produire à plusieurs niveaux. Le tableau suivant décrit les actions que vous pouvez effectuer en réponse à un échec de test irrégulier:
Échec |
Action |
---|---|
L'émulateur n'a pas répondu pendant une seconde, ce qui a déclenché un délai d'inactivité. |
Réexécuter le test ayant échoué |
Échec du démarrage de l'émulateur |
Réexécuter l'intégralité de la tâche |
Une erreur de connexion s'est produite lors de la phase de règlement du code |
Redémarrer le workflow |
Il est important de consigner et de suivre les parties du système irrégulières, et d'investir dans la fiabilité et la rapidité de la CI, en ne s'appuyant que sur les nouvelles tentatives