Confira abaixo alguns recursos que estão disponíveis na maioria dos sistemas de CI.
Ambiente
É importante escolher e entender o ambiente de hardware e software em que o sistema executa o fluxo de trabalho. Considerações importantes para aplicativos Android são:
- Plataforma: Linux, Mac, Windows e as versões deles.
- Memória disponível: a criação de apps e a execução de emuladores pode usar muita memória RAM, e geralmente é necessário ajustar parâmetros, como o tamanho de heap da JVM, para evitar erros de falta de memória.
- Software pré-instalado: os sistemas de CI geralmente fornecem imagens com um grande conjunto de ferramentas já disponíveis, como o Java Development Kit (JDK), o Android Software Development Kit (SDK), ferramentas de build, plataformas e emuladores.
- Arquitetura do executor e conjunto de instruções: ARM, x86. Isso é importante ao usar emuladores.
- Variáveis de ambiente: algumas são definidas pelo sistema de CI (por exemplo:
ANDROID_HOME) e podem ser definidas por conta própria para, por exemplo, evitar a fixação de credenciais no código do fluxo de trabalho.
Há muitos outros aspectos que precisam ser considerados, como o número de núcleos disponíveis e se a virtualização está ativada para executar emuladores.
Registros e relatórios
Quando uma etapa falha, o sistema de CI notifica você e, geralmente, não permite que você mescle a alteração. Para descobrir o que deu errado, procure erros nos registros.
Além disso, a criação e o teste geram relatórios que geralmente são armazenados como artefatos desse build específico. Dependendo do sistema de CI, você pode usar plug-ins para visualizar os resultados desses relatórios.
Tempos de execução de cache e CI
Os sistemas de CI usam um cache de build para acelerar o processo. Na forma mais simples, eles salvam todos os arquivos de cache do Gradle após um build bem-sucedido e os restauram antes de um novo. Isso depende do recurso de cache de build do Gradle (link em inglês) e precisa ser ativado no seu projeto.
Confira algumas maneiras de melhorar os tempos de execução e a confiabilidade:
- Módulos: detectar quais módulos são afetados por uma mudança e apenas criar e testar.
- Pular caches: se o build incluir scripts que um desenvolvedor modificou, ignore os caches de build. É mais seguro criar do zero.
- Testes de fragmento: especialmente testes instrumentados, pode ser útil fragmentar testes em vários dispositivos. Isso é compatível com o executor do Android, dispositivos gerenciados pelo Gradle e o Firebase Test Lab.
- Builds de fragmento: é possível fragmentar o build em várias instâncias de servidor.
- Cache remoto: também é possível usar o cache remoto do Gradle (link em inglês).
Repetir testes com falha
Instabilidade refere-se a testes ou ferramentas que falham intermitentemente. Sempre tente encontrar e corrigir os problemas que geram builds e testes instáveis, mas alguns deles são difíceis de reproduzir, especialmente ao executar testes instrumentados. Uma estratégia comum é repetir as execuções de teste sempre que elas falharem, até um número máximo de tentativas.
Não há uma maneira única de configurar novas tentativas, porque elas podem ocorrer em vários níveis. A tabela a seguir descreve a ação que você pode realizar em resposta a uma falha no teste instável:
Falha |
Ação |
|---|---|
O emulador não respondeu por um segundo, acionando um tempo limite |
Executar novamente o teste com falha |
Falha ao inicializar o emulador |
Executar toda a tarefa novamente |
Ocorreu um erro de conexão durante a fase de finalização da compra do código |
Reiniciar o fluxo de trabalho |
É importante registrar e monitorar quais partes do sistema estão instáveis e investir para manter a CI confiável e rápida, contando apenas com novas tentativas