💆🏾 🏬 🕵🏻 CI TeamCity - Automação de processos de compilação de testes de Android e UI ◾️ 😻 👩🏽‍🎨

Neste artigo, chamo a atenção para instruções de instalação e configuração do TeamCity para automatizar a montagem e o teste de projetos Android no Windows.

Também prestarei atenção aos recursos de configuração do ambiente para o projeto Android (que encontrei no processo de pesquisa) e a vários tipos de coisas que podem ajudar a facilitar a vida do testador e desenvolvedor iniciante.

Objetivos.

Ao atualizar o código do projeto, o seguinte deve ocorrer:

Projeto de construção automática
Executar autotestes da interface do usuário
Exportando arquivos de depuração e liberação APK para testes manuais subseqüentes
Notificar todos os membros da equipe de desenvolvimento dos resultados

Plano:

Instale e configure o Java JDK
Instale e configure o Android SDK
Definindo uma gradle separada para depuração
Preparando um projeto Android
Instale o TeamCity Server e o Build Agent
Configurando o TeamCity Project → Compilar para a compilação do projeto e obter a instalação APK
Configurar etapas de construção com autotestes da interface do usuário

Parte principal

1. Instalando e configurando o Java JDK

Ao contrário da crença popular sobre a instalação da versão mais recente do Java, o JetBrains em seu site oficial publica a versão recomendada do Java SDK: link

Instala a versão recomendada: link

Instale também variáveis de ambiente:

JAVA_HOME- caminho para a pasta com o SKD Java para usar o CI.

Exemplo:

C:\Java\jdk1.8.0_181
Melhor inserir variáveis do sistema.
Caminho - caminho para a pasta com Java SKD para uso na linha de comando.

Exemplo:

C:\Java\jdk1.8.0_181\bin
Melhor inserir variáveis do usuário.

Verificamos a instalação:

No CMD em qualquer diretório que inserimos: java -version

Java deve responder que é:

2. Instalar e configurar o Android SDK

Não instalaremos as ferramentas do Android SDK separadamente. O Android proibiu a criação de projetos a partir da linha de comando. Também será mais conveniente depurar possíveis erros se instalarmos imediatamente o Android Studio.

Instale a versão mais recente: link

Instale também Variáveis de ambiente:

ANDROID_HOME
Exemplo: C:\Users\1\AppData\Local\Android\Sdk

ANDROID_AVD_HOME
Exemplo: C:\Users\1\.android\avd

Caminho:

Exemplo: C:\Users\1\AppData\Local\Android\Sdk\platform-tools\- inicie os utilitários do console por nós e pelo CI.

Verifique: digite CMD: adb --help

obtenha informações sobre a versão atual e os comandos disponíveis:

Caminho:

Exemplo: C:\Users\1\AppData\Local\Android\Sdk\emulator\- inicie o emulador a partir do console por nós e pela CI.

Verifique: digitamos o CMD emulator -version

. Obtemos informações sobre a versão atual:

3. Instalação do Gradle O Gradle

está incluído no Android Studio, mas colocaremos outro para a depuração no console.

A versão não é importante, porque pressupõe-se que o projeto será lançado através do wrapper Gradle.

Sugiro instalar uma versão semelhante à usada no projeto, por exemplo, Gradle 3.3. Link .

Também instalamos variáveis de ambiente:

GRADLE_HOME- não há necessidade, porque O CI usará o Gradle Android Studio.

GRADLE_USER_HOME

Exemplo: c:/gradle-cache

Real para Windows Server, como sem ele, durante a montagem do projeto, todas as bibliotecas Gradle baixadas serão armazenadas emC:\Windows\System32\config\systemprofile\.gradleCI adicional não poderá acessar esses arquivos.

Caminho:

C:\Gradle\gradle-3.3\bin- o caminho para a pasta Gradle para uso conveniente na linha de comando.

Confira: digitamos o CMD gradle -v

Recebemos informações sobre a versão atual:

4. Preparação do projeto Android

4.1. Crie um projeto de teste no Android Studio.

Tipo Atividade - Atividade de Navegação Inferior. Isso será útil posteriormente para a criação de um teste de interface do usuário.

4.2 Desative o Gradle Daemon continuamente para que o Gradle Daemon não apareça no IC:

Adicione no arquivo gradle.properties:
add org.gradle.daemon=false

4.3. Também adicionamos ao arquivo .gitignore(a seu gosto) para que arquivos extras não sejam deixados no VCS. 4.4 Crie um keystore (ou use um existente) na pasta do projeto. Link .

.gradle
.idea
/build/
local.properties

4.5 Adicione links ao keystore ao Gradle para que possamos criar um APK completo.

Exemplo:

android{  
    ... //  
    signingConfigs {
        release {
            storeFile file("keystorefile.jks") //        
            storePassword "Password" //  
            keyAlias "android" // keyAlias,     
            keyPassword "Password" //  APK
        }
    }

    ... //  
     buildTypes {
        release {
            ... //  
            signingConfig signingConfigs.release //  APK
        }
    }
}

4.6 Para testar a integridade do sistema, montaremos um novo projeto a partir da linha de comando. Entre no CMD:

cd < >

Por exemplo: C:\Users\1\Documents\GitHub\Command2

Vá para o projeto.

Enter: Estamos

gradlew assembleDebug

aguardando a conclusão da montagem.

Se tudo estiver bem, obtemos o resultado BUILD SUCCESSFUL.

Vamos para a pasta do projeto: app\build\outputs\apk\debug

contém um novo arquivo APK que pode ser instalado no dispositivo e verificamos se tudo funciona.

4.7 Também verificaremos se as ferramentas SDK e o gerenciador AVD foram lançados.

4.7.1 Inicie o Android Studio e crie um emulador. É claro que você pode criá-lo na linha de comando, mas temos o shell da interface do usuário instalado, é um pecado não usá-lo.

Ferramentas → AVD Manager:

A versão SDK do emulador criada deve ser pelo menos tão grande quanto o nosso projeto SDK.

4.7.2 Criou um emulador. Vamos verificar o seu lançamento a partir do console. Entramos na linha de comando:

start /min emulator -avd < >

Exemplo:

start /min emulator -avd Pixel_2_API_25

Observe que usamos uma função /minpara iniciar o emulador em segundo plano. Caso contrário, ele não teria permitido inserir novos comandos no CMD.
O dispositivo está executando:

4.7.3. Verificamos a instalação do APK coletado.

Entramos no CMD:

adb install <path_to_apk>

Exemplo: com

adb install C:\Users\1\Documents\GitHub\Command2\app\release\app-release.apk

sucesso:

4.7.4. Verificamos o lançamento do APK instalado.

Entramos no CMD:

adb shell monkey -p < > -c android.intent.category.LAUNCHER 1

Exemplo: O

adb shell monkey -p com.panarik.command -c android.intent.category.LAUNCHER 1

aplicativo foi iniciado:

4.7.5. Carregamos o projeto em um repositório remoto, por exemplo, no GitHub. Verifique se o projeto será baixado:

Instale o Git BASH (se usarmos o Git VCS). Link .

Clonamos o projeto de um repositório remoto. Entre no console Git BASH:

git clone < .git>

Exemplo:

git clone https://github.com/panarik/Command2.git

Nós vemos o resultado. O projeto foi copiado para uma pasta local:

Tudo está pronto para instalar e configurar o TeamCity. Por que estamos fazendo exercícios com a linha de comando e não instalando imediatamente o TeamCity. Será muito mais conveniente garantir antecipadamente que o projeto esteja funcionando, para que no futuro seja mais fácil localizar possíveis erros na fase de construção no TeamCity.

5. Instalando o TeamCity Server e o Build Agent

Não descreverei o processo de instalação em detalhes. Ele está no guia oficial e em muitas outras fontes. Porta do servidor TeamCity, proponho definir não-padrão, para que seja mais difícil calcular as verificações de porta.

6. Configurando o TeamCity Project → Compilar

Em configurações gerais, você só precisa definir o caminho para a saída do APK:

Exemplo:

app\build\outputs\apk\release\app-release.apk

6.1. Configurando as raízes do TeamCity VCS

Tudo é padrão. Em nosso projeto, usamos o Git, para inseri-lo e um link para o repositório remoto. Exemplo:

https://github.com/panarik/Command2.git

6.2. Configuração de compilação do TeamCity

Adicione uma Etapa de compilação, que irá compilar o projeto e exibir o APK. Em nosso projeto, usamos Gradle.

Digite o campo Tarefas Gradle:

clean build assembleDebug --no-daemon(--no-daemon apenas por precaução, e isso deve funcionar como um subscrito para o arquivo que fizemos na seção 4.2)

Clique em Executar, obtemos o APK.

7. Configurando etapas de construção com autotestes da interface do usuário Chegamos

à parte mais interessante, a saber, o lançamento automático dos testes da interface do usuário.

As etapas serão iniciadas usando arquivos .BAT. É muito mais conveniente escrever um código, alterá-lo rapidamente, sem precisar acessar a interface do usuário do TeamCity etc.

7.1 Primeiro, crie uma etapa de compilação com o emulador em execução.

Você pode criar o URL para o BATnik completamente, por conveniência, criei Environment no TeamCity BAT_FILEScom o caminho para a pasta com o BATniks:

escrevemos o código inicial do emulador no arquivo.

Exemplo:

start /min "emulator" /D "C:\Users\1\AppData\Local\Android\Sdk\emulator" emulator.exe -avd Pixel_2_API_25 -no-snapshot-save -no-boot-anim

Lista de comandos e parâmetros em um link externo: site .

7.2 Crie uma etapa de construção com uma pausa enquanto o emulador é carregado. Você pode registrar imediatamente o primeiro passo no .BAT, mas ficará mais claro.

Um exemplo de uma equipe que espionou na Internet:

adb wait-for-device shell 'while [[ -z $(getprop sys.boot_completed) ]]; do sleep 1; done; input keyevent 82'

A partir da interface do usuário, será assim:

Lista de todas as equipes fora do site: link.

7.3 Execute o teste.

Também a partir da linha de comando. Tudo é individual aqui.

Exemplo de comando:

gradlew connectedDebugAndroidTest

7.4. Paramos o emulador.

Exemplo de comando:

adb -s emulator-5554 emu kill

Processo concluído.

Você também pode fazer o upload do relatório em uma etapa separada. Por padrão, ele é salvo na pasta do projeto.

Muito obrigado pela atenção!

Se alguém tiver conselhos sobre como melhorar o código para etapas e sugestões para melhorar, ficarei muito grato.

CI TeamCity - Automação de processos de compilação de testes de Android e UI

Objetivos.

Plano:

Parte principal

More articles: