Get best of the week

Código aberto: infraestrutura de teste CI / CD e Avito para Android

Mudamos a infraestrutura de código-fonte aberto do Avito para Android: plug-ins, emuladores e bibliotecas de teste Gradle. Nosso código será útil na automação de CI / CD e também facilitará a gravação e o suporte de autotestes.

Neste artigo de revisão, explicaremos por que decidimos tornar nosso trabalho aberto, sobre as bibliotecas mais significativas do projeto e orientaremos para onde ir com questões emergentes. Analisaremos detalhadamente as bibliotecas individuais, os plugins Gradle e nossas abordagens de desenvolvimento nos seguintes materiais.



Quem nós somos e o que nós fazemos


Estamos trabalhando na indústria do Android na equipe da plataforma Speed. Somos quatro:
Seryozha Boishtyan Conta do Twitter do
engenheiro sênior



Dima Voronin Conta de
engenheiro líder no
Twitter


Zhenya Krivobokov
Engenheiro sênior
Conta no Twitter


Daniil Popov Conta de
engenheiro sênior do
Twitter


Somos responsáveis ​​por fornecer alterações em todos os aplicativos Avito Android aos usuários mais rapidamente. Nossa área de responsabilidade inclui:

  • Trabalho local com o projeto: para que tudo seja montado rapidamente e o IDE não fique lento.
  • Pipeline de CI: testes, todas as verificações possíveis.
  • CD: ferramentas para engenheiros de lançamento.

Por que precisamos de código aberto


Queríamos não apenas espelhar o código no repositório aberto no Github, mas fazê-lo para o benefício de nós mesmos e da comunidade de engenharia. Os principais motivos para levar o projeto ao código aberto são cinco:

  • Obter feedback.
  • Influenciar os padrões da indústria.
  • Aprender coisas novas.
  • Afetar bibliotecas de terceiros.
  • Impulsione sua marca pessoal.

Vamos examiná-los brevemente.

Obtenha feedback e facilite a reutilização do código


Fazemos ajustes para os engenheiros da Avito, e nossos usuários precisam de todas as soluções para funcionar. Nos falta a visão dos desenvolvedores que resolvem problemas semelhantes. Vai ser legal se eles apontarem problemas na implementação interna e a conveniência de se conectar ao nosso projeto.

Já vimos como a portabilidade de código para o Github destacou os problemas de reutilização. Quando você entende que outras empresas podem usar isso, analisa a arquitetura de maneira diferente. Reutilizar código não é um fim em si. Mas esse critério externo diz muito sobre a qualidade da arquitetura e sua flexibilidade.

Influenciar os padrões da indústria


Desenvolvemos infraestrutura para aplicativos móveis desde 2017 e falamos regularmente sobre isso em conferências e reuniões:


Além das histórias, sempre quisemos compartilhar o código e dar a oportunidade de reutilizá-lo. De fato, muitos desenvolvedores do Android enfrentam desafios semelhantes:

  • Como escrever autotestes para que eles se beneficiem.
  • Como executá-los em solicitações pull.
  • Como mais barato para manter a infraestrutura.

Não há soluções geralmente aceitas e estabelecidas para essas tarefas - cada empresa opera à sua maneira. Compartilhamos nossas melhores práticas para que em novos projetos os desenvolvedores não precisem coletar informações pouco a pouco sobre o teste de aplicativos móveis e a criação de CI / CD. Eu gostaria de ter soluções prontas para problemas de rotina, em vez de escrever minha bicicleta. E, mesmo que ninguém use o código do projeto em sua forma original, os desenvolvedores poderão espionar nossas abordagens e melhorar suas próprias bibliotecas.

Aprenda explicando para outras pessoas


Apenas colocar o código em código aberto não é suficiente. Práticas, abordagens, maneiras de encontrar problemas e tomar decisões são importantes. Mostrando a eles, verificamos como nossas ideias e propostas prontas funcionam fora do Avito.

Afeta bibliotecas de terceiros e corrija seus problemas mais rapidamente


Imagine que você está enfrentando um problema em um Android ou biblioteca e não consegue encontrar uma solução alternativa. Você precisa de ajuda da comunidade ou dos autores do código. Você fez uma pergunta no Stack Overflow, criou um bug no Google IssueTracker, descreveu tudo em detalhes, mas o problema não é reproduzido. Você é solicitado para um caso de teste. Tudo isso leva tempo extra.

O código aberto ajuda a criar um exemplo reproduzível mais rapidamente. Temos um aplicativo de teste que usa parte da infraestrutura. Sua principal tarefa é a alimentação de cães, ou seja, o mais cedo possível para verificar com um exemplo simples e isolado que tudo funciona. Mas esse mesmo aplicativo facilita a exibição de erros. Quando damos um exemplo reproduzível em uma biblioteca estrangeira, seu autor fica mais fácil de entender qual é o problema. Isso aumenta as chances de que ele realize melhorias.

A popularidade de um projeto de código aberto também aumenta a probabilidade de que eles prestem atenção em você. Apontar um problema em uma biblioteca com muitas estrelas e usuários aumenta a pressão, é mais difícil ignorar. Obter esse resultado sem código aberto é mais difícil - seu aplicativo deve ser super popular ou você deve conhecê-lo pessoalmente.

RP e motivação pessoal


Por último, mas não menos importante, é o ganho pessoal. Todo mundo se beneficia da publicidade do trabalho diário. A empresa atrai a atenção devido a um produto útil, e desenvolvemos uma marca pessoal como engenheiro e obtemos motivação adicional para o trabalho. Você não precisa mais procurar tempo à noite para seus próprios projetos ou confirmar em bibliotecas de código aberto de terceiros.

O que foi trazido para o código aberto


Nós colocar quase todos os nossos Android e CI / CD infra-estrutura de teste para o repositório Github . Para facilitar a navegação do projeto por outros desenvolvedores, todos os módulos são agrupados por objetivo:




Vou observar algumas das bibliotecas mais significativas.

Corredor de teste


Este é um plugin gradle para executar testes de instrumentação. O analógico mais próximo é o Marathon , mas o nosso é escrito apenas para Android.

Corredor de teste:

  • Descreve quais testes executar. Há filtragem por anotações, pacotes, pelos resultados do último lançamento.
  • Descreve em quais emuladores executar testes. Faz o backup deles no Kubernetes ou se conecta a emuladores locais.
  • Define as condições para reiniciar os testes.
  • Envia um relatório final com os resultados da execução do teste.

Os resultados são armazenados no TMS personalizado (sistema de gerenciamento de teste), não em código aberto. Estamos trabalhando na possibilidade de conectar outra implementação.



Análise de impacto


Temos cerca de 1600 testes de instrumentação e testes de unidade de 10K. Gostaríamos de executar todos os testes para qualquer alteração de código, mas isso não é possível - a execução levará muito tempo.

Uma solução simples é dividir manualmente os testes em diferentes conjuntos, por exemplo, testes de fumaça, rápidos, lentos e executar apenas uma parte. Mas com essa abordagem, sempre há a chance de ocorrer um erro, porque não está claro qual conjunto de testes é ideal. A solução ideal é entender qual conjunto mínimo de testes verificará todas as alterações. Isso é chamado de análise de impacto de teste . Escrevemos

um plugin Gradle que procura alterações nos módulos, analisa testes e determina quais executar.



Os principais módulos e abordagens são descritos em mais detalhes na documentação do projeto .
Agora ela não é muito boa e nem tudo é traduzido. Queremos facilitar a compreensão da documentação e precisamos da sua ajuda. Diga-nos o que finalizar e corrigir no texto em nosso bate-papo por telegrama .



Como nossas bibliotecas podem ser úteis


Como o projeto possui muitos componentes, seu uso depende das suas necessidades. Se você estiver resolvendo um problema semelhante ou apenas quiser entender a tecnologia, sinta-se à vontade para nos escrever em um bate-papo por telegrama em russo ou em inglês . Vamos dizer o que sabemos, tentar ajudar e mostrar exemplos relevantes.

Você pode perguntar qualquer coisa:

  • Como você trabalha com testes instáveis?
  • Por que tanto código? Ele é inútil.
  • Por que todo o código dos plugins Gradle, não scripts Python?

Se você deseja usar um módulo específico, pode experimentá-lo em um aplicativo de teste . Agora, mostra um exemplo do uso do test runner.

Infelizmente, ainda temos poucos exemplos de reutilização em outros projetos, portanto, a integração ainda pode revelar restrições desconhecidas. Escreva-nos se isso acontecer, e veremos o que precisa ser finalizado.

Conclusão


Nos seguintes artigos, planejamos falar sobre:

  • Nosso corredor de teste.
  • Anatomia do teste - o que acontece ao pressionar o botão "Executar" no IDE para obter o resultado.
  • Como lutamos contra a instabilidade de testes e infraestrutura.
  • Nossas abordagens para escrever infraestrutura.
  • Como reduzimos o tempo de lançamento de mês para semana.

Existem idéias sobre tópicos mais gerais:

  • Como começar a escrever testes.
  • Fundamentos de teste para iniciantes - sobre abordagens e tecnologias comuns.

Diga-nos nos comentários o que você estará interessado em saber. Então, entenderemos qual texto escrever primeiro.

More articles:


All Articles