Get best of the week

As ferramentas do DevOps não são apenas para o DevOps. O processo de construção de uma infraestrutura de automação de teste do zero

Parte 1: Web / Android


Nota : este artigo é uma tradução para o russo do artigo original  “As ferramentas do DevOps não são apenas para o DevOps. Construindo uma infraestrutura de automação de teste do zero. " No entanto, todas as ilustrações, links, citações e termos são armazenados no idioma original para evitar distorção de significado quando traduzidos para o russo. Desejo-lhe um estudo agradável!



Atualmente, a especialidade DevOps é uma das mais populares do setor de TI. Se você abrir sites populares de pesquisa de emprego e definir um filtro de salário, verá que os trabalhos relacionados ao DevOps estão no topo da lista. No entanto, é importante entender que isso se refere principalmente à posição de 'Sênior', o que implica que o candidato tenha um alto nível de habilidades, conhecimento de tecnologias e ferramentas. Ele também vem com um alto grau de responsabilidade associado ao bom funcionamento da produção. No entanto, começamos a esquecer o que é DevOps. Inicialmente, não era uma pessoa ou departamento específico. Se procurarmos as definições desse termo, encontraremos muitos substantivos bonitos e corretos, como metodologia, práticas, filosofia cultural, um grupo de conceitos e assim por diante.

Minha especialização é engenheiro de automação de controle de qualidade, mas acredito que não deve estar relacionado apenas à criação de autoteste ou ao desenvolvimento de uma arquitetura para uma estrutura de teste. Em 2020, também é necessário o conhecimento da infraestrutura de automação. Isso permite que você organize o processo de automação, desde o lançamento dos testes até o fornecimento de resultados a todas as partes interessadas, de acordo com os objetivos. Como resultado, as habilidades de DevOps são essenciais para este trabalho. E tudo isso é bom, mas, infelizmente, há um problema ( spoiler: este artigo faz tentativas de simplificar esse problema) Está no fato de que o DevOps é complicado. E isso é óbvio, porque as empresas não pagam muito pelo que é fácil de fazer ... No mundo do DevOps, há um grande número de ferramentas, termos, práticas que precisam ser dominadas. Isso é especialmente difícil no início de uma carreira e depende da experiência técnica acumulada.


Fonte: http://maximelanciauxbi.blogspot.com/2017/04/devops-tools.html

Aqui, provavelmente concluiremos a parte introdutória e focaremos no objetivo deste artigo. 

Sobre o que é este artigo


Neste artigo, vou compartilhar minha experiência na construção de uma infraestrutura de automação de teste. Na Internet, você pode encontrar muitas fontes de informações sobre várias ferramentas e como usá-las, mas eu gostaria de considerá-las exclusivamente no contexto da automação. Acredito que muitos engenheiros de automação estão familiarizados com uma situação em que ninguém executa os testes desenvolvidos, exceto você, e não se importa com o suporte deles. Como resultado, os testes se tornam obsoletos e você precisa gastar tempo atualizando-os. Novamente, no início de uma carreira, isso pode ser uma tarefa bastante difícil: decidir corretamente quais ferramentas devem ajudar a resolver esse problema, como escolher, configurar e mantê-las. Alguns testadores pedem ajuda do DevOps (pessoas) e, para ser sincero, essa abordagem funciona.Em muitos casos, essa pode ser a única opção, pois não temos a visibilidade de todas as dependências. Mas, como sabemos, os DevOps são caras muito ocupados, porque devem pensar na infraestrutura de toda a empresa, na implantação, no monitoramento, nos microsserviços e em outras tarefas semelhantes, dependendo da organização / equipe. Como geralmente acontece, a automação não é uma prioridade. Nesse caso, devemos tentar fazer o melhor possível do começo ao fim. Isso reduzirá vícios, acelerará o fluxo de trabalho, melhorará nossas habilidades e nos permitirá ver uma imagem mais ampla do que está acontecendo.microsserviços e outras tarefas semelhantes, dependendo da organização / equipe. Como geralmente acontece, a automação não é uma prioridade. Nesse caso, devemos tentar fazer o melhor possível do começo ao fim. Isso reduzirá vícios, acelerará o fluxo de trabalho, melhorará nossas habilidades e nos permitirá ver uma imagem mais ampla do que está acontecendo.microsserviços e outras tarefas semelhantes, dependendo da organização / equipe. Como geralmente acontece, a automação não é uma prioridade. Nesse caso, devemos tentar fazer o melhor possível do começo ao fim. Isso reduzirá vícios, acelerará o fluxo de trabalho, melhorará nossas habilidades e nos permitirá ver uma imagem mais ampla do que está acontecendo.

O artigo apresenta as ferramentas mais populares e populares e mostra como usá-las para a construção passo a passo da infraestrutura de automação. Cada grupo é representado por ferramentas que foram testadas na experiência pessoal. Mas isso não significa que você deve usar o mesmo. As ferramentas em si não são importantes, elas aparecem e se tornam obsoletas. Nossa tarefa de engenharia é entender os princípios básicos: por que precisamos desse grupo de ferramentas e quais tarefas de trabalho podemos resolver com a ajuda deles. Portanto, no final de cada seção, deixo links para ferramentas semelhantes que podem ser usadas em sua organização.

O que não está neste artigo


Mais uma vez, o artigo não trata de ferramentas específicas; portanto, não haverá inserções de código na documentação e nas descrições de comandos específicos. Mas, no final de cada seção, deixo links para um estudo detalhado.

Isso se deve ao fato de que: 

  • esse material é muito fácil de encontrar em várias fontes (documentação, livros, cursos em vídeo);
  • se começarmos a aprofundar, teremos que escrever 10, 20, 30 partes deste artigo (enquanto os planos 2-3);
  • Eu só não quero perder seu tempo, porque talvez você queira usar outras ferramentas para alcançar os mesmos objetivos.

Prática


Eu realmente gostaria que esse material fosse útil para todos os leitores, e não apenas fosse lido e esquecido. Em qualquer estudo, a prática é um componente muito importante. Para fazer isso, preparei um repositório GitHub com um guia passo a passo sobre como fazer tudo do zero . Você também estará aguardando a lição de casa para ter certeza de que não copiou sem pensar linhas de comandos executados

Plano


DegrauTecnologiaFerramentas
1 1Execução local (prepare testes de demonstração da web / android e execute localmente) Node.js, Selênio, Appium
2Sistemas de controle de versão Git
3ContainerizaçãoDocker, grade de selênio, selenoide (Web, Android)
4CI / CDGitlab ci
5Plataformas em nuvemPlataforma de nuvem do Google
6OrquestraçãoKubernetes
7Infraestrutura como um código (IaC)Terraform, ansible

A estrutura de cada seção


Para manter a narrativa em uma forma visual, cada seção é descrita da seguinte maneira:

  • ,
  • ,
  • ,
  • ,
  • .

1.



Esta é apenas uma etapa preparatória para executar os testes de demonstração localmente e verificar se eles são aprovados com êxito. Na parte prática, o Node.js é usado, mas a linguagem e a plataforma de programação também não são importantes e você pode usar as que são usadas na sua empresa. 

No entanto, como ferramenta de automação, recomendo usar o Selenium WebDriver para plataformas Web e Appium para a plataforma Android, respectivamente, pois nas próximas etapas usaremos imagens do Docker projetadas especificamente para trabalhar especificamente com essas ferramentas. Além disso, referindo-se aos requisitos de vagas, essas ferramentas são as mais requisitadas no mercado.

Como você deve ter notado, consideramos apenas testes na Web e Android. Infelizmente, o iOS é uma história completamente diferente (graças à Apple). Planejo demonstrar as soluções e práticas relacionadas ao iOS nas seguintes partes.

Valor para infraestrutura de automação


Do ponto de vista da infraestrutura, um lançamento local não carrega nenhum valor. Você só verifica se os testes são executados na máquina local em navegadores e simuladores locais. Mas, em qualquer caso, este é um ponto de partida necessário.

Ilustração do estado atual da infraestrutura




Links de aprendizagem



Ferramentas similares


  • qualquer linguagem de programação que você goste em conjunto com Selenium / Appium - tests;
  • quaisquer testes;
  • qualquer corredor de teste.

2. Sistemas de controle de versão (Git)


Resumo da tecnologia


Não será uma grande descoberta para ninguém se eu disser que o sistema de controle de versão é uma parte extremamente importante do desenvolvimento, tanto em equipe quanto individualmente. Com base em várias fontes, podemos dizer com segurança que o Git é o representante mais popular. O sistema de controle de versão oferece muitas vantagens, como troca de código, armazenamento de versão, restauração de ramificações anteriores, monitoramento do histórico do projeto, backups. Não discutiremos cada item detalhadamente, pois tenho certeza de que você o conhece e o usa no trabalho diário. Mas, se de repente não, recomendo interromper a leitura deste artigo e preencher essa lacuna o mais rápido possível.

Valor para infraestrutura de automação


E aqui você pode fazer uma pergunta razoável: “Por que ele nos fala sobre o Git? Todo mundo sabe e usa isso para o código de desenvolvimento e o código de autoteste. ” Você estará absolutamente certo, mas neste artigo estamos falando sobre infraestrutura e esta seção desempenha o papel de uma prévia da seção 7: “Infraestrutura como código (IaC)”. Para nós, isso significa que toda a infraestrutura, incluindo a de teste, é descrita na forma de código, para que também possamos aplicar sistemas de versão a ela e obter vantagens semelhantes para o código de desenvolvimento e automação.

Veremos o IaC com mais detalhes na etapa 7, mas mesmo agora você pode começar a usar o Git localmente criando um repositório local. O panorama geral será expandido quando adicionarmos um repositório remoto à infraestrutura.

Ilustração do estado atual da infraestrutura




Links de aprendizagem



Ferramentas similares



3. Containerização (Docker)


Resumo da tecnologia


Para demonstrar como a conteinerização mudou as regras do jogo, vamos voltar várias décadas. Naqueles dias, as pessoas compravam e usavam máquinas servidor para executar aplicativos. Mas na maioria dos casos, os recursos necessários para o lançamento não eram conhecidos antecipadamente. Como resultado, as empresas gastaram dinheiro na compra de servidores poderosos e caros, mas algumas dessas capacidades não foram completamente utilizadas.

O próximo estágio da evolução foram as máquinas virtuais (VMs), que resolveram o problema de gastar dinheiro em recursos não utilizados. Essa tecnologia tornou possível executar aplicativos independentemente um do outro no mesmo servidor, alocando espaço completamente isolado. Mas, infelizmente, qualquer tecnologia tem suas desvantagens. A inicialização de uma VM requer um sistema operacional completo que consome CPU, RAM, armazenamento e, dependendo do sistema operacional, é necessário considerar o custo de uma licença. Esses fatores afetam a velocidade do download e complicam a portabilidade.

E assim chegamos à contêiner. E, novamente, essa tecnologia resolveu o problema anterior, pois os contêineres não usam um sistema operacional completo, o que permite liberar um grande número de recursos e fornece uma solução rápida e flexível para portabilidade.

Obviamente, a tecnologia de contêineres não é nova e foi introduzida pela primeira vez no final dos anos 70. Naqueles dias, havia muitas pesquisas, bases e tentativas. Mas foi Docker quem adaptou essa tecnologia e a tornou facilmente acessível às massas. Atualmente, quando falamos de contêineres, na maioria dos casos, queremos dizer Docker. Quando falamos sobre contêineres Docker, queremos dizer contêineres Linux. Podemos usar os sistemas Windows e macOS para executar contêineres, mas é importante entender que, nesse caso, uma camada adicional aparece. Por exemplo, o Docker no Mac lança silenciosamente contêineres dentro de uma VM Linux leve. Voltaremos a este tópico quando discutirmos o lançamento de emuladores Android dentro de contêineres, e é aqui que uma nuance muito importante aparece, que precisa ser analisada com mais detalhes.

Valor para infraestrutura de automação


Descobrimos que a conteinerização e o Docker são legais. Vejamos isso no contexto da automação, porque cada ferramenta ou tecnologia deve resolver um problema. Vamos denotar os problemas óbvios da automação de teste no contexto dos testes de interface do usuário:

  • um grande número de dependências ao instalar o Selenium e especialmente o Appium;
  • problemas de compatibilidade entre versões de navegadores, simuladores e drivers;
  • falta de espaço isolado para navegadores / simuladores, o que é especialmente crítico para o lançamento paralelo;
  • É difícil gerenciar e manter se você precisar executar 10, 50, 100 ou até 1000 navegadores ao mesmo tempo.

Mas como o Selenium é a ferramenta de automação mais popular e o Docker é a ferramenta de contêiner mais popular, não deve surpreender ninguém que alguém tenha tentado combiná-los para obter uma ferramenta poderosa para resolver os problemas acima. Vamos considerar essas soluções em mais detalhes. 

Grade de selênio na janela de encaixe

Essa ferramenta é a mais popular no mundo do Selenium para iniciar e gerenciar vários navegadores em várias máquinas a partir de um site central. Para começar, você deve registrar pelo menos 2 partes: Hub e Nó (s). Um hub é um site central que recebe todas as solicitações de testes e as distribui para os Nós apropriados. Para cada Nó, podemos definir uma configuração específica, por exemplo, especificando o navegador desejado e sua versão. No entanto, ainda precisamos cuidar de drivers de navegador compatíveis e instalá-los nos nós necessários. Por esse motivo, a grade do Selenium não é usada em sua forma pura, exceto quando precisamos trabalhar com navegadores que não podem ser instalados no sistema operacional Linux.Para todos os outros casos, o uso de uma imagem do Docker para executar o Hub e os nós da grade do Selenium é uma solução muito flexível e correta. Essa abordagem simplifica bastante o gerenciamento de nós, pois podemos escolher a imagem que precisamos com versões compatíveis já instaladas de navegadores e drivers.

Apesar do feedback negativo sobre a estabilidade, especialmente ao executar um grande número de nós em paralelo, a grade do Selenium ainda é a ferramenta mais popular para executar testes de Selenium em paralelo. É importante observar que, no código aberto, várias melhorias e modificações dessa ferramenta aparecem constantemente, enfrentando vários gargalos.

Selenoid para web

Essa ferramenta é uma inovação no mundo do Selenium, pois funciona imediatamente e facilitou muito a vida de muitos engenheiros de automação. Primeiro de tudo, essa não é outra modificação da grade do Selenium. Em vez disso, os desenvolvedores criaram uma versão completamente nova do Selenium Hub na linguagem Golang, que, em conjunto com imagens leves do Docker para vários navegadores, deu ímpeto ao desenvolvimento da automação de testes. Além disso, no caso do Selenium Grid, devemos determinar todos os navegadores necessários e suas versões com antecedência, o que não é um problema ao trabalhar com apenas um navegador. Mas quando se trata de vários navegadores suportados, o Selenoid é a solução número um, graças ao recurso 'navegador sob demanda'. Tudo o que é necessário para nós é pré-carregar as imagens necessárias nos navegadores e atualizar o arquivo de configuração,com o qual o Selenoid interage. Depois que o Selenoid recebe uma solicitação dos testes, ele inicia automaticamente o contêiner certo com o navegador certo. Quando o teste é concluído, o Selenoid descarta o contêiner, liberando recursos para as consultas a seguir. Essa abordagem elimina completamente o conhecido problema de 'degradação de nós', que costumamos ver na grade do Selenium.

Mas, infelizmente, o Selenoid ainda não é uma bala de prata. Temos o recurso de navegador sob demanda, mas o recurso de recursos sob demanda ainda não está disponível. Para usar o Selenoid, precisamos implantá-lo em um hardware físico ou VM, o que significa que precisamos saber com antecedência quantos recursos precisam ser alocados. Acredito que isso não é um problema para pequenos projetos que executam 10, 20 ou até 30 navegadores em paralelo. Mas e se precisarmos de 100, 500, 1000 e mais? Não faz sentido manter e pagar por tantos recursos o tempo todo. Nas seções 5 e 6 deste artigo, discutiremos soluções que permitem escalar, reduzindo significativamente os custos da empresa.

Selenoid para Android

Após o sucesso do Selenoid como uma ferramenta para automação da web, as pessoas queriam algo semelhante para o Android. E aconteceu - o Selenoid foi lançado com suporte para Android. Do ponto de vista do usuário de alto nível, o princípio de operação é semelhante à automação da Web. A única diferença é que, em vez de contêineres com navegadores, o Selenoid lança contêineres com emuladores Android. Na minha opinião, hoje é a ferramenta gratuita mais poderosa para executar testes do Android em paralelo.

Eu realmente não gostaria de falar sobre os aspectos negativos desta ferramenta, já que eu realmente gosto muito. Mas ainda existem as mesmas desvantagens relacionadas à automação da Web relacionadas ao dimensionamento. Além disso, precisamos falar sobre outra limitação, que pode ser uma surpresa se sintonizarmos o instrumento pela primeira vez. Para executar imagens do Android, precisamos de uma máquina física ou VM com suporte à virtualização aninhada. No guia prático, demonstro como ativar isso em uma VM Linux. No entanto, se você é um usuário do macOS e deseja implantar o Selenoid localmente, não será possível executar testes do Android. Mas você sempre pode iniciar a VM do Linux localmente com a 'virtualização aninhada' configurada e implantar o Selenoid dentro.

Ilustração do estado atual da infraestrutura


No contexto deste artigo, adicionaremos 2 ferramentas para ilustrar a infraestrutura. Trata-se da grade do Selenium para testes na Web e do Selenoid para Android. No manual do GitHub, também mostrarei como usar o Selenoid para executar testes na web. 



Links de aprendizagem



Ferramentas similares


  • Existem outras ferramentas de conteinerização, mas o Docker é o mais popular. Se você quiser tentar outra coisa, lembre-se de que as ferramentas que analisamos para executar os testes do Selenium em paralelo não funcionarão imediatamente.  
  • Como já mencionado, há muitas modificações na grade do Selenium, por exemplo, Zalenium .

4. CI / CD


Resumo da tecnologia


A prática da integração contínua é bastante popular no desenvolvimento e está em pé de igualdade com os sistemas de controle de versão. Apesar disso, sinto que há uma confusão na terminologia. Nesta seção, gostaria de descrever três modificações desta tecnologia do meu ponto de vista. Na Internet, você pode encontrar muitos artigos com diferentes interpretações, e é absolutamente normal que sua opinião seja diferente. O mais importante é que você esteja no mesmo comprimento de onda que seus colegas.

Portanto, existem três termos: IC - Integração Contínua (CD), CD - Entrega Contínua (CD) e novamente CD - Implantação Contínua (CD). ( Além disso, usarei esses termos em inglês) Cada modificação adiciona algumas etapas extras ao seu pipeline de desenvolvimento. Mas a palavra contínuo é a mais importante. Nesse contexto, queremos dizer algo que acontece do começo ao fim, sem interrupção ou exposição manual. Vamos dar uma olhada no CI & CD e CD neste contexto.

  • Integração Contínua é o passo inicial na evolução. Depois de enviar o novo código para o servidor, esperamos receber um feedback rápido de que tudo está em ordem com nossas alterações. Normalmente, o IC inclui o lançamento de ferramentas estáticas de análise de código e testes de unidade / API internos, permitindo que você obtenha informações sobre nosso código alguns segundos / minutos depois.
  • Continuous Delivery , /UI-. , CI. -, . -, test/staging — . , , .
  • Continuous Deployment , (release) production, . release , smoke — production . Continuous Deployment . - , , Continuous (). , Continuous Delivery.


Nesta seção, devo esclarecer que, quando falamos sobre testes de interface do usuário de ponta a ponta, isso implica que devemos implantar nossas alterações e serviços relacionados nos ambientes de teste. Integração Contínua - o processo não é aplicável a esta tarefa e devemos ter o cuidado de implementar pelo menos as práticas de Entrega Contínua. A Implantação Contínua também faz sentido no contexto dos testes de interface do usuário, se vamos executá-los na produção.

E antes de olharmos para a ilustração da mudança na arquitetura, quero dizer algumas palavras sobre o GitLab CI. Ao contrário de outras ferramentas de CI / CD, o GitLab fornece um repositório remoto e muitos outros recursos avançados. Portanto, o GitLab é mais do que CI. Inclui controle de origem pronto para uso, gerenciamento ágil, pipelines de CI / CD, ferramentas de registro e coleta de métricas. A arquitetura do GitLab consiste no CI / CD do Gitlab e no GitLab Runner. Faço uma breve descrição do site oficial:
O CI / CD do Gitlab é um aplicativo da web com uma API que armazena seu estado em um banco de dados, gerencia projetos / cria e fornece uma interface de usuário. GitLab Runner é uma aplicação que processa compilações. Ele pode ser implantado separadamente e funciona com o GitLab CI / CD por meio de uma API. Para testes em execução, você precisa da instância do Gitlab e do Runner.








5.



Nesta seção, falaremos sobre uma tendência popular chamada 'nuvens públicas'. Apesar dos enormes benefícios que as tecnologias de virtualização e contêineres descritas acima fornecem, ainda precisamos de recursos de computação. As empresas compram servidores caros ou alugam datacenters, mas, neste caso, é necessário fazer cálculos (às vezes irrealistas) de quantos recursos precisaremos, se os usaremos 24 horas por dia, sete dias por semana e para quais fins. Por exemplo, a produção requer um servidor funcionando 24 horas, mas precisamos de recursos semelhantes para testes após o expediente? Também depende do tipo de teste que está sendo realizado. Um exemplo seria o teste de estresse / estresse, que planejamos executar após horas para obter resultados no dia seguinte. Mas definitivamenteA disponibilidade do servidor 24 horas não é necessária para auto-testes de ponta a ponta e, especialmente, para ambientes de teste manual. Para tais situações, seria bom receber tantos recursos quanto necessário sob demanda, usá-los e parar de pagar quando não forem mais necessários. Além disso, seria bom recebê-los instantaneamente clicando em alguns cliques do mouse ou executando alguns scripts. Para isso, nuvens públicas são usadas. Vejamos a definição:Para isso, nuvens públicas são usadas. Vejamos a definição:Para isso, nuvens públicas são usadas. Vejamos a definição:
“A nuvem pública é definida como serviços de computação oferecidos por provedores de terceiros pela Internet pública, disponibilizando-os para quem quiser usá-los ou comprá-los. "Eles podem ser gratuitos ou vendidos sob demanda, permitindo que os clientes paguem apenas por uso pelos ciclos de CPU, armazenamento ou largura de banda que consomem".

Há uma opinião de que as nuvens públicas são caras. Mas a idéia principal é reduzir os custos da empresa. Como mencionado anteriormente, as nuvens públicas permitem obter recursos sob demanda e pagar apenas pelo tempo em que são usados. Além disso, às vezes esquecemos que os funcionários são pagos e os especialistas também são um recurso caro. Lembre-se de que as nuvens públicas facilitam bastante o suporte à infraestrutura, o que permite que os engenheiros se concentrem nas tarefas mais importantes. 

Valor para infraestrutura de automação


Quais recursos específicos precisamos para testes de interface do usuário de ponta a ponta? Essas são principalmente máquinas virtuais ou clusters (falaremos sobre o Kubernetes na próxima seção) para iniciar navegadores e emuladores. Quanto mais navegadores e emuladores quisermos executar ao mesmo tempo, mais CPU e memória serão necessários e mais dinheiro teremos que pagar por isso. Assim, as nuvens públicas no contexto da automação de teste nos permitem lançar um grande número (100, 200, 1000 ...) de navegadores / emuladores sob demanda, obter resultados de teste o mais rápido possível e parar de pagar por essas capacidades insanamente intensivas em recursos. 

Os provedores de nuvem mais populares são Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP). O guia prático fornece exemplos de uso do GCP, mas, em geral, não importa o que você usará para tarefas de automação. Todos eles oferecem aproximadamente a mesma funcionalidade. Normalmente, para selecionar um provedor, o gerenciamento concentra-se em toda a infraestrutura e nos requisitos de negócios da empresa, que estão além do escopo deste artigo. Será mais interessante para os engenheiros de automação comparar o uso de provedores de nuvem usando plataformas de nuvem especificamente para fins de teste, como Sauce Labs, BrowserStack, BitBar e assim por diante. Então vamos fazer o mesmo! Na minha opinião, o Sauce Labs é o farm de testes em nuvem mais famoso, então eu o levei para comparação. 

GCP vs. Sauce Labs for Automation:

imagine que precisamos executar 8 testes na Web e 8 testes ao Android ao mesmo tempo. Para fazer isso, usaremos o GCP e executaremos 2 máquinas virtuais com o Selenoid. No primeiro, levantaremos 8 contêineres com navegadores. No segundo - 8 recipientes com emuladores. Vamos dar uma olhada nos preços:  


Para executar um contêiner com o Chrome, precisamos de uma máquina n1-standard-1 . No caso do Android, este será o n1-standard-4 para um emulador. De fato, uma maneira mais flexível e barata é definir valores de usuário específicos para CPU / Memória, mas no momento não é importante para comparação com Sauce Labs.

E aqui estão as taxas para usar o Sauce Labs:


Suponho que você já tenha notado a diferença, mas ainda assim darei uma tabela com os cálculos para nossa tarefa:

Recursos necessáriosMontlyHorário de trabalho (das 8h às 20h)Horário de trabalho + preemptivo
Gcp para webn1-padrão-1 x 8 = n1-padrão-8$ 194,1823 dias * 12h * 0,38 = 104,88 $ 23 dias * 12h * 0,08 = 22,08 $
Sauce Labs para WebTestes paralelos do Virtual Cloud8$ 1.559--
GCP para Androidn1-padrão-4 x 8: n1-padrão-16$ 776,7223 dias * 12h * 1,52 = $ 419,52 23 dias * 12h * 0,32 = 88,32 $
Sauce Labs para AndroidTestes paralelos do Real Device Cloud 8$ 1.999--

Como você pode ver, a diferença de custo é enorme, especialmente se você executar os testes apenas no período de doze horas de trabalho. Mas você pode reduzir ainda mais os custos usando máquinas preemptivas. O que é isso?
A preemptible VM is an instance that you can create and run at a muchower price than normal instances. However, Compute Engine might terminate (preempt) these instances if it requires access to those resources for other tasks. Preemptible instances are excess Compute Engine capacity, so their availability varies with usage.

If your apps are fault-tolerant and can withstand possible instance preemptions, then preemptible instances can reduce your Compute Engine costs significantly. For example, batch processing jobs can run on preemptible instances. If some of those instances terminate during processing, the job slows but does not completely stop. Preemptible instances complete your batch processing tasks without placing additional workload on your existing instances and without requiring you to pay full price for additional normal instances.

E ainda não é o fim! Na verdade, tenho certeza de que ninguém executa testes por 12 horas sem intervalo. E, nesse caso, você pode iniciar e parar automaticamente as máquinas virtuais quando elas não forem necessárias. O tempo real de uso pode cair para 6 horas por dia. Em seguida, o pagamento no contexto de nossa tarefa diminuirá em até US $ 11 por mês para 8 navegadores. Isso não é perfeito? Porém, com máquinas preemptivas, devemos ter cuidado e estar preparados para interrupções e operação instável, embora essas situações possam ser fornecidas e processadas programaticamente. Vale a pena!

Mas de maneira alguma digo "nunca use fazendas de teste na nuvem". Eles têm várias vantagens. Antes de tudo, essa não é apenas uma máquina virtual, mas uma solução completa para testar a automação com um conjunto de funcionalidades prontas para uso: acesso remoto, logs, capturas de tela, gravação de vídeo, vários navegadores e dispositivos móveis físicos. Em muitas situações, essa pode ser uma alternativa chique indispensável. Especialmente, as plataformas de teste são úteis para a automação do IOS quando as nuvens públicas podem oferecer apenas sistemas Linux / Windows. Mas falar sobre iOS estará em artigos futuros. Eu recomendo sempre olhar para a situação e começar com as tarefas: em algumas, é mais barato e mais eficiente usar nuvens públicas e, em algumas plataformas de teste, definitivamente vale o dinheiro gasto.

Ilustração do estado atual da infraestrutura




Links de aprendizagem



Ferramentas semelhantes:



6. Orquestração


Resumo da tecnologia


Tenho boas notícias - quase chegamos ao final do artigo! No momento, nossa infraestrutura de automação consiste em testes da Web e Android, que executamos em paralelo o GitLab CI, usando ferramentas com suporte ao Docker: grade Selenium e Selenoid. Além disso, usamos máquinas virtuais criadas por meio do GCP para levantar contêineres com navegadores e emuladores. Para reduzir custos, iniciamos essas máquinas virtuais somente sob demanda e paramos quando o teste não é executado. Existe mais alguma coisa que possa melhorar nossa infraestrutura? A resposta é sim! Conheça o Kubernetes (K8s)!

Para começar, considere como as palavras orquestração, cluster e Kubernetes estão relacionadas. Em um nível alto, a orquestração é um sistema que implanta e gerencia aplicativos. Para automatizar os testes, essas aplicações em contêineres são a grade Selenium e a Selenoid. Docker e K8s se complementam. O primeiro é usado para implantar aplicativos, o segundo para orquestração. Por sua vez, o K8s é um cluster. A tarefa do cluster é usar VMs como nós, o que permite instalar várias funcionalidades, programas e serviços em um servidor (cluster). Se algum nó travar, outros nós serão ativados, o que garante que nosso aplicativo funcione sem problemas. Além disso, o K8s possui uma funcionalidade importante relacionada à escala,graças à qual obtemos automaticamente a quantidade ideal de recursos, com base na carga e nas restrições estabelecidas.

Na verdade, implantar manualmente o Kubernetes do zero é uma tarefa completamente não trivial. Vou deixar um link para o Kubernetes The Hard Way, um conhecido guia prático, e se você estiver interessado, poderá praticar. Mas, felizmente, existem formas e ferramentas alternativas. O mais fácil deles é usar o Google Kubernetes Engine (GKE) no GCP, que permitirá que você obtenha um cluster pronto depois de alguns cliques. Para iniciar o estudo, recomendo que você use essa abordagem, pois ela permitirá que você se concentre em aprender a usar o K8s para suas tarefas, em vez de explorar como os componentes internos devem ser integrados. 

Valor para infraestrutura de automação


Considere alguns dos recursos significativos que o K8s fornece:

  • : multi-nodes , VMs;
  • : , ;
  • (Self-healing): pods ( );
  • : ,

Mas os K8s ainda não são uma bala de prata. Para entender todas as vantagens e limitações no contexto das ferramentas que estamos considerando (grade Selenium, Selenoid), discutimos brevemente a estrutura dos K8s. O cluster contém dois tipos de nós: nós principais e nós dos trabalhadores. Os nós principais são responsáveis ​​por gerenciar, implantar e agendar decisões. Nós dos trabalhadores é onde os aplicativos estão sendo executados. Nós também contém um ambiente de inicialização de contêiner. No nosso caso, esse é o Docker, responsável pelas operações relacionadas aos contêineres. Mas existem soluções alternativas como o container. É importante entender que o dimensionamento ou a autocorreção não se aplicam diretamente aos contêineres. Isso é feito adicionando / diminuindo o número de pods, que por sua vez contêm contêineres (geralmente um contêiner por pod, mas pode haver mais dependendo da tarefa). A hierarquia de alto nível são nós de trabalho, dentro dos quais são pods, dentro dos quais os contêineres são gerados.

A função de dimensionamento é essencial e pode ser aplicada aos nós dentro de um conjunto de nós do cluster e aos pods dentro de um nó. Existem 2 tipos de escala que se aplicam a nós e pods. O primeiro tipo de escala horizontal ocorre devido a um aumento no número de nós / pods. Este tipo é mais preferido. O segundo tipo, respectivamente, é vertical. O dimensionamento é feito aumentando o tamanho dos nós / pods, não o número deles.

Agora considere nossas ferramentas no contexto dos termos acima.

Grade de selênio

Como mencionado anteriormente, a grade Selenium é uma ferramenta muito popular e não é uma surpresa que ela tenha sido contêiner. Portanto, não é de surpreender que a grade do Selenium possa ser implantada nos K8s. Um exemplo de como fazer isso pode ser encontrado no repositório oficial do K8s. Como sempre, anexo links no final da seção. Além disso, o guia prático mostra como fazer isso na série Terraform. Há também uma instrução sobre como dimensionar o número de pods que contêm contêineres com navegadores. Mas o recurso de dimensionamento automático no contexto do K8s ainda não é uma tarefa óbvia. Quando iniciei o estudo, não encontrei nenhuma orientação ou recomendação prática.Após vários estudos e experiências com o suporte da equipe do DevOps, optamos pela abordagem de aumentar contêineres com os navegadores desejados em um pod, localizado dentro de um nó de trabalho. Este método nos permite aplicar a estratégia de escala horizontal de nós, aumentando seu número. Espero que, no futuro, a situação mude, e veremos cada vez mais descrições das melhores abordagens e soluções chave na mão, especialmente após o lançamento da grade Selenium 4 com uma arquitetura interna modificada.especialmente após o lançamento da grade Selenium 4 com uma arquitetura interna redesenhada.especialmente após o lançamento da grade Selenium 4 com uma arquitetura interna redesenhada.

Selenoid :

Atualmente, implantar o Selenoid nos K8s é a maior decepção. Eles não são compatíveis. Teoricamente, podemos criar um contêiner Selenoid dentro de um pod, mas quando o Selenoid começa a lançar contêineres com navegadores, eles ainda estarão dentro do mesmo pod. Isso impossibilita o dimensionamento e, como resultado, o trabalho do Selenoid dentro do cluster não será diferente do trabalho dentro da máquina virtual. O fim da história.

Moon :

conhecendo esse gargalo enquanto trabalhava com o Selenoid, os desenvolvedores lançaram uma ferramenta mais poderosa chamada Moon. Essa ferramenta foi originalmente concebida para trabalhar com o Kubernetes e, como resultado, você pode e deve usar a função de escala automática. Além disso, eu diria que no momento é o únicouma ferramenta no mundo do Selenium, que prontamente possui suporte de cluster K8s nativo ( não está mais disponível, consulte a próxima ferramenta ). Um recurso importante do Moon que fornece esse suporte é: 
Completamente apátrida. O Selenoid armazena na memória informações sobre as sessões do navegador em execução no momento. Se, por algum motivo, seu processo falhar - todas as sessões em execução serão perdidas. A Moon, ao contrário, não possui um estado interno e pode ser replicada nos datacenters. As sessões do navegador permanecem ativas, mesmo que uma ou mais réplicas sejam desativadas.
Portanto, Moon é uma ótima solução, mas com um problema, não é gratuito. O preço depende do número de sessões. Somente sessões 0-4 podem ser iniciadas gratuitamente, o que não é particularmente útil. Mas, a partir da quinta sessão, você terá que pagar US $ 5 por cada. A situação pode diferir de empresa para empresa, mas, no nosso caso, o uso do Moon não faz sentido. Como descrevi acima, podemos iniciar VMs com o Selenium Grid sob demanda ou aumentar o número de nós no cluster. Por aproximadamente um pipeline, lançamos 500 navegadores e paramos todos os recursos após a conclusão dos testes. Se usássemos o Moon, teríamos que pagar um extra de 500 x 5 = $ 2500 por mês e não importa com que frequência executamos os testes. E, novamente, eu não digo "não use Moon". Para suas tarefas, essa pode ser uma solução indispensável, por exemplo,se você tem muitos projetos / equipes em sua organização e precisa de um enorme cluster comum para todos. Como sempre, deixo um link no final e recomendo fazer todos os cálculos necessários no contexto da sua tarefa.

Callisto : ( Atenção! Isso não está no artigo original e está contido apenas na tradução em russo )

Como eu disse, o Selenium é uma ferramenta muito popular e a indústria de TI está se desenvolvendo muito rapidamente. Enquanto eu trabalhava na tradução, uma nova ferramenta promissora da Callisto apareceu na rede (Olá, Cypress e outros assassinos do Selenium). Ele funciona nativamente com o K8s e permite executar contêineres Selenoid em pods, distribuídos por nós. Tudo funciona imediatamente, incluindo o dimensionamento automático. Ficção, mas é necessário testar. Eu já consegui implantar essa ferramenta e fazer algumas experiências. Mas é muito cedo para tirar conclusões, depois de receber os resultados a longa distância, talvez eu revise os artigos a seguir. Até agora, deixo apenas links para pesquisas independentes.  







7. (IaC)



E assim chegamos à última seção. Geralmente, essa tecnologia e tarefas relacionadas não são incluídas na área de responsabilidade dos engenheiros de automação. E há razões para isso. Em primeiro lugar, em muitas organizações, os problemas de infraestrutura estão sob o controle do departamento de DevOps e as equipes de desenvolvimento não se importam com o funcionamento do pipeline e como dar suporte a tudo relacionado a ele. Em segundo lugar, sejamos honestos, a prática de "Infraestrutura como um código (IaC)" ainda não é aplicada em muitas empresas. Mas definitivamente se tornou uma tendência popular e é importante tentar se envolver em processos, abordagens e ferramentas relacionadas. Ou, pelo menos, fique a par dos desenvolvimentos.

Vamos começar com a motivação para usar essa abordagem. Já discutimos que, para executar os testes no GitlabCI, precisamos de pelo menos os recursos para executar o Gitlab Runner. E para executar contêineres com navegadores / emuladores, precisamos reservar uma VM ou cluster. Além de testar os recursos, precisamos de um número significativo de capacidades para oferecer suporte a ambientes de desenvolvimento, preparação, produção, que também incluem bancos de dados, planejamentos automáticos, configurações de rede, balanceadores de carga, direitos do usuário etc. Uma questão fundamental é o esforço necessário para apoiar tudo isso. Existem várias maneiras pelas quais podemos fazer alterações e implantar atualizações. Por exemplo, no contexto do GCP, podemos usar o console da interface do usuário no navegador e executar todas as ações clicando nos botões.Uma maneira alternativa seria usar chamadas de API para interagir com entidades da nuvem ou usar o utilitário de linha de comando gcloud para executar as manipulações necessárias. Porém, com um número realmente grande de entidades e elementos de infraestrutura diferentes, torna-se difícil ou mesmo impossível executar todas as operações manualmente. Além disso, todas essas ações manuais são incontroláveis. Não podemos enviá-los para revisão antes da execução, usar o sistema de controle de versão e reverter rapidamente as edições que levaram ao incidente. Para resolver esses problemas, os engenheiros criaram e estão criando scripts bash / shell automáticos, o que não é muito melhor que os métodos anteriores, pois não são tão fáceis de ler, entender, manter e modificar em um estilo procedural.

Neste artigo e instruções, eu uso 2 ferramentas relacionadas à prática de IaC. Estes são Terraform e Ansible. Alguns acreditam que não faz sentido usá-los simultaneamente, pois suas funcionalidades são semelhantes e são intercambiáveis. Mas o fato é que, inicialmente, eles enfrentam tarefas completamente diferentes. E o fato de essas ferramentas se complementarem foi confirmado em uma apresentação conjunta por desenvolvedores representando HashiCorp e RedHat. A diferença conceitual é que o Terraform é uma ferramenta de provisionamento para gerenciar os próprios servidores. Enquanto o Ansible é uma ferramenta de gerenciamento de configuração cuja tarefa é instalar, configurar e gerenciar o software nesses servidores.

Outro recurso importante dessas ferramentas é o estilo de escrever código. Diferente do bash e do Ansible, o Terraform usa um estilo declarativo com base na descrição do estado final desejado, que deve ser alcançado como resultado da execução. Por exemplo, se vamos criar 10 VMs e aplicar as alterações através do Terraform, obtemos 10 VMs. Se você aplicar o script novamente, nada acontecerá, pois já temos 10 VMs, e o Terraform sabe disso, porque armazena o estado atual da infraestrutura em um arquivo de estado. Mas o Ansible usa uma abordagem processual e, se você pedir para ele criar 10 VMs, na primeira execução obteremos 10 VMs, da mesma forma que o Terraform. Mas, após reiniciar, já teremos 20 VMs. Isso é uma diferença importante.No estilo processual, não armazenamos o estado atual e simplesmente descrevemos a sequência de etapas que devem ser concluídas. Obviamente, podemos lidar com várias situações, adicionar várias verificações quanto à existência de recursos e ao estado atual, mas não faz sentido desperdiçar nosso tempo e fazer esforços para controlar essa lógica. Além disso, isso aumenta o risco de cometer erros. 

Resumindo tudo isso, podemos concluir que, para provisionar servidores, o Terraform e a notação declarativa são uma ferramenta mais adequada. Mas o trabalho de gerenciamento de configuração é melhor delegado à Ansible. Tendo resolvido isso, vejamos exemplos de uso no contexto da automação.

Valor para infraestrutura de automação


É importante entender apenas que a infraestrutura de automação de teste deve ser considerada como parte de toda a infraestrutura da empresa. Isso significa que todas as práticas de IaC devem ser aplicadas globalmente aos recursos de toda a organização. Quem é responsável por isso depende dos seus processos. A equipe do DevOps é mais experiente nesses assuntos, eles vêem toda a imagem do que está acontecendo. No entanto, os engenheiros de controle de qualidade estão mais envolvidos no processo de automação predial e na estrutura do pipeline, o que lhes permite ver melhor todas as alterações e oportunidades de melhoria necessárias. A melhor opção é trabalhar em conjunto, compartilhar conhecimentos e idéias para alcançar o resultado esperado. 

Aqui estão alguns exemplos de uso do Terraform e do Ansible no contexto da automação de testes e das ferramentas que discutimos anteriormente:

1. Descreva por meio do Terraform as características e parâmetros necessários de VMs e clusters.

2. Instale com Ansible as ferramentas necessárias para teste: janela de encaixe, Selenoid, Selenium Grid e faça o download das versões necessárias de navegadores / emuladores.

3. Descreva por meio do Terraform as características da VM na qual o GitLab Runner será lançado.

4. Instale com o Ansible GitLab Runner e as ferramentas relacionadas necessárias, defina as configurações e configurações.

Ilustração do estado atual da infraestrutura



Links de estudo:



Ferramentas similares




Para resumir!


DegrauTecnologiaFerramentasValor para infraestrutura de automação
1 1Local runningNode.js, Selenium, Appium
  • web mobile
  • ( Node.js)

2Version control systems Git

3ContainerisationDocker, Selenium grid, Selenoid (Web, Android)
  • ,

4CI / CDGitlab CI
  • /

5Cloud platformsGoogle Cloud Platform
  • ( )

6OrchestrationKubernetes/ pods:
  • /

7Infraestrutura como um código (IaC)Terraform, ansible
  • Benefícios semelhantes com infraestrutura de desenvolvimento
  • Todos os benefícios do versionamento de código
  • Fácil de fazer alterações e manter
  • Totalmente automatizado



Diagramas de mapas mentais: evolução da infraestrutura


step1: Local


step2: vcs


step3: Containerização 


step4: CI / CD 


step5: plataformas em nuvem


step6: orquestração


step7: IaC


Qual é o próximo?


Portanto, este é o fim do artigo. Mas, em conclusão, gostaria de estabelecer alguns acordos com você.

Da sua parte
Como foi dito no começo, eu gostaria que o artigo fosse de uso prático e o ajudasse a aplicar o conhecimento adquirido em trabalhos reais. Eu adiciono novamente um link para um guia prático .

Mas mesmo depois disso, não pare, pratique, estude os links e livros relevantes, descubra como ele funciona na sua empresa, encontre lugares que podem ser aprimorados e participem. Boa sorte

Do meu lado

Do cabeçalho, fica claro que essa foi apenas a primeira parte. Apesar de ser bastante amplo, tópicos importantes ainda não foram divulgados aqui. Na segunda parte, pretendo examinar a infraestrutura de automação no contexto do IOS. Devido às limitações da Apple em relação à execução de simulações iOS apenas em sistemas macOS, nosso conjunto de soluções foi reduzido. Por exemplo, não podemos usar o Docker para executar um simulador ou nuvens públicas para executar máquinas virtuais. Mas isso não significa que não há outras alternativas. Vou tentar mantê-lo atualizado com soluções avançadas e ferramentas modernas!

Além disso, não mencionei tópicos muito grandes relacionados ao monitoramento. Na Parte 3, considerarei as ferramentas mais populares para monitorar a infraestrutura, bem como quais dados e métricas considerar.

E finalmente. No futuro, pretendo lançar um curso em vídeo sobre a construção de uma infraestrutura de teste e ferramentas populares. Atualmente, existem muitos cursos e palestras sobre DevOps na Internet, mas todos os materiais são apresentados no contexto do desenvolvimento, mas não a automação de teste. Nesse caso, eu realmente preciso de feedback, se este curso for interessante e valioso para a comunidade de testadores e engenheiros de automação. Desde já, obrigado!

More articles:


All Articles