Parte 1: Web / Android
Nota: este artigo é uma tradução para o português do artigo original No entanto, todas as ilustrações, links, citações e termos foram mantidos no idioma original para evitar a distorção do significado durante a tradução para o português. Desejo a você um bom estudo!
Atualmente, a profissão de DevOps é uma das mais demandadas na indústria de TI. Se você abrir sites populares de busca de emprego e aplicar um filtro de salários, verá que as vagas relacionadas a DevOps estão no topo da lista. No entanto, é importante entender que isso se refere principalmente à posição de ‘Senior’, o que implica que o candidato possui um alto nível de habilidades, conhecimento de tecnologias e ferramentas. Isso também vem acompanhado de um alto nível de responsabilidade, relacionado ao funcionamento contínuo da produção. Contudo, temos esquecido o que é DevOps. Inicialmente, não era uma pessoa ou departamento específico. Pesquisando definições desse termo, encontramos muitos substantivos bonitos e corretos, como metodologia, práticas, filosofia cultural, grupo de conceitos e assim por diante.
Minha especialização é engenheiro de automação de testes (QA automation engineer), mas eu acredito que não deve estar apenas relacionada à escrita de testes automáticos ou ao desenvolvimento da arquitetura de frameworks de teste. Em 2020, o conhecimento em infraestrutura de automação também é indispensável. Isso permite organizar o processo de automação de forma independente, desde a execução dos testes até a apresentação dos resultados a todas as partes interessadas de acordo com os objetivos estabelecidos. Como resultado, as habilidades de DevOps são um fator essencial para realizar esse trabalho. E tudo isso é bom, mas, infelizmente, existe um problema (spoiler: este artigo tenta simplificar esse problema). Ele reside no fato de que DevOps é complicado. E isso é evidente, pois as empresas não gastarão muito por algo que pode ser feito facilmente... No mundo do DevOps, há uma grande quantidade de ferramentas, termos e práticas que precisam ser dominados. Isso é especialmente difícil no início da carreira e depende da experiência técnica acumulada.
Fonte:
Aqui provavelmente terminaremos a parte introdutória e nos concentraremos no objetivo deste artigo.
Sobre o que é este artigo
Neste artigo, vou compartilhar minha experiência na construção de uma infraestrutura para automação de testes. É possível encontrar muitas fontes de informação na internet sobre diversas ferramentas e como utilizá-las, mas gostaria de abordá-las exclusivamente no contexto da automação. Acredito que muitos engenheiros de automação conhecem a situação em que os testes desenvolvidos, além de você mesmo, ninguém mais os executa ou se preocupa em mantê-los. Como resultado, os testes se tornam obsoletos e é preciso gastar tempo para atualizá-los. Novamente, no início da carreira, isso pode ser uma tarefa bastante desafiadora: resolver de forma adequada quais ferramentas devem ajudar a resolver esse problema, como escolhê-las, configurá-las e mantê-las. Alguns testadores recorrem à ajuda do DevOps (pessoas) e, sejamos sinceros, essa abordagem funciona. Em muitos casos, essa pode ser a única opção, já que nos falta visibilidade sobre todas as dependências. Mas, como sabemos, os DevOps são pessoas muito ocupadas, pois precisam pensar na infraestrutura de toda a empresa, no deployment, na monitoração, em microsserviços e em outras tarefas semelhantes, dependendo da organização/equipe. Como costuma acontecer, a automação não é uma prioridade. Nesse caso, devemos tentar fazer o máximo possível de nossa parte, do início ao fim. Isso reduzirá as dependências, acelerará o fluxo de trabalho, aprimorará nossas habilidades e permitirá que tenhamos uma visão mais ampla do que está acontecendo.
O artigo apresenta as ferramentas mais demandadas e populares e mostra como utilizá-las para construir a infraestrutura de automação passo a passo. Cada grupo é representado por ferramentas que foram testadas com experiência pessoal. Mas isso não significa que você deva usar as mesmas. As próprias ferramentas não são o mais importante, elas surgem e se tornam obsoletas. Nossa tarefa como engenheiros é entender os princípios básicos: por que precisamos desse grupo de ferramentas e quais tarefas de trabalho podemos resolver com a ajuda delas. Portanto, no final de cada seção, deixo links para ferramentas semelhantes que podem estar sendo utilizadas em sua organização.
O que não está neste artigo
Mais uma vez, ressalto que o artigo não é sobre ferramentas específicas, portanto, não haverá trechos de código da documentação ou descrições de comandos específicos. No entanto, ao final de cada seção, deixarei links para um estudo mais detalhado.
Isso é feito porque:
- este material é muito fácil de encontrar em várias fontes (documentação, livros, cursos em vídeo);
- se começarmos a nos aprofundar, teremos que escrever 10, 20, 30 partes deste artigo (quando o plano é de 2 a 3);
- eu simplesmente não quero desperdiçar seu tempo, pois talvez você queira usar outras ferramentas para atingir os mesmos objetivos.
Prática
Eu realmente gostaria que este material fosse útil para cada leitor, e não apenas lido e esquecido. Em qualquer aprendizado, a prática é uma parte muito importante. Para isso, preparei. Também haverá uma tarefa de casa para ter certeza de que você não copiou as linhas dos comandos sem pensar.
Plano
Passo
Tecnologia
Ferramentas
1
Execução local (preparar testes de demonstração web / android e executá-los localmente)
Node.js, Selenium, Appium
2
Sistemas de controle de versão
Git
3
Contêinerização
Docker, grid do Selenium, Selenoid (Web, Android)
4
CI / CD
Gitlab CI
5
Plataformas em nuvem
Google Cloud Platform
6
Orquestração
Kubernetes
7
Infraestrutura como código (IaC)
Terraform, Ansible
Estrutura de cada seção
Para manter a narrativa visual, cada seção é descrita segundo o seguinte plano:
- uma breve descrição da tecnologia,
- o valor para a infraestrutura de automação,
- uma ilustração do estado atual da infraestrutura,
- links para estudo,
- ferramentas semelhantes.
1. Execução local de testes
Breve descrição da tecnologia
Este é apenas um passo preparatório para rodar testes de demonstração localmente e verificar se eles passam com sucesso. Na parte prática, usa-se Node.js, mas a linguagem de programação e a plataforma também não são importantes, podendo ser utilizadas aquelas que estão em sua empresa.
No entanto, como ferramentas de automação, recomendo usar Selenium WebDriver para plataformas web e Appium para a plataforma Android, pois nos próximos passos usaremos imagens do Docker que são adaptadas especificamente para trabalhar com essas ferramentas. Além disso, olhando para as exigências nas vagas de emprego, essas ferramentas são as mais procuradas no mercado.
Como você pôde notar, estamos abordando apenas testes web e Android. Infelizmente, iOS é uma história completamente diferente (obrigado, Apple). Planejo demonstrar soluções e práticas relacionadas ao iOS nas próximas partes.
Valor para a infraestrutura de automação
Do ponto de vista da infraestrutura, a execução local não oferece valor algum. Você apenas verifica se os testes funcionam na máquina local, em navegadores e simuladores locais. Mas, de qualquer forma, esse é um ponto de partida necessário.
Ilustração do estado atual da infraestrutura
Links para estudo
Ferramentas semelhantes
- qualquer linguagem de programação que você preferir, em combinação com testes do Selenium/Appium;
- quaisquer testes;
- qualquer executor de testes.
2. Sistemas de controle de versão (Git)
Breve descrição da tecnologia
Não será uma grande revelação se eu disser que um sistema de controle de versão é uma parte extremamente importante do desenvolvimento, tanto em equipe quanto individualmente. Com base em várias fontes, pode-se afirmar com segurança que o Git é o representante mais popular. O sistema de controle de versão oferece várias vantagens, como compartilhamento de código, armazenamento de versões, recuperação para branches anteriores, monitoramento do histórico do projeto, backups. Não vamos discutir cada ponto em detalhes, pois tenho certeza de que você está bem familiarizado e o utiliza em seu trabalho diário. Mas, caso não esteja, recomendo que pare de ler este artigo e o faça o mais rápido possível.
Valor para a infraestrutura de automação
E aqui você pode fazer uma pergunta razoável: 'Por que ele está nos falando sobre o Git? Todo mundo sabe e usa tanto para desenvolvimento de código quanto para código de testes automatizados.' Você estará absolutamente certo, mas neste artigo estamos falando sobre infraestrutura, e esta seção serve como uma introdução à seção 7: 'Infraestrutura como Código (IaC)'. Para nós, isso significa que toda a infraestrutura, incluindo a de testes, é descrita em forma de código; portanto, também podemos aplicar sistemas de versionamento a ela e obter benefícios semelhantes aos do desenvolvimento de código e automação.
Vamos analisar o IaC com mais detalhes no passo 7, mas mesmo agora você pode começar a usar o Git localmente, criando um repositório local. A visão geral será ampliada quando adicionarmos um repositório remoto à infraestrutura.
Ilustração do estado atual da infraestrutura
Links para estudo
Ferramentas semelhantes
3. Containização (Docker)
Breve descrição da tecnologia
Para demonstrar como a contenção mudou as regras do jogo, vamos voltar várias décadas no tempo. Naquela época, as pessoas adquiriam e usavam máquinas de servidores para rodar aplicativos. Mas, na maioria das vezes, os recursos necessários para a execução não eram conhecidos antecipadamente. Como resultado, as empresas gastavam dinheiro comprando servidores poderosos e caros, mas parte desse poder não era completamente utilizado.
O próximo estágio da evolução foram as máquinas virtuais (VM), que resolveram o problema do gasto em recursos não utilizados. Essa tecnologia permitiu executar aplicativos de forma independente dentro de um único servidor, alocando um espaço completamente isolado. Mas, infelizmente, qualquer tecnologia tem suas desvantagens. A execução de uma VM requer um sistema operacional completo, que consome CPU, RAM, armazenamento e, dependendo do SO, também precisa-se considerar os custos de licença. Esses fatores afetam a velocidade de inicialização e dificultam a portabilidade.
E assim chegamos à contenção. Novamente, essa tecnologia resolveu o problema anterior, pois os contêineres não usam um SO completo, permitindo liberar uma grande quantidade de recursos e proporcionando uma solução rápida e flexível para a portabilidade.
Claro, a tecnologia de contêineres não é algo novo e foi apresentada pela primeira vez no final dos anos 70. Naquela época, muitas pesquisas, desenvolvimentos e tentativas foram feitas. Mas foi o Docker que adapta essa tecnologia e a torna facilmente acessível às massas. Hoje em dia, quando falamos sobre contêineres, na maioria das vezes nos referimos ao Docker. Quando falamos sobre contêineres Docker, estamos nos referindo a contêineres Linux. Podemos usar sistemas Windows e macOS para executar contêineres, mas é importante entender que, nestes casos, uma camada adicional aparece. Por exemplo, o Docker no Mac executa contêineres silenciosamente dentro de uma VM Linux leve. Voltaremos a esse assunto quando discutirmos a execução de emuladores Android dentro de contêineres, pois aqui surge um ponto muito importante que precisa ser analisado mais detalhadamente.
Valor para a infraestrutura de automação
Descobrimos que a contêinerização e o Docker são incríveis. Vamos analisar isso no contexto da automação, pois cada ferramenta ou tecnologia deve resolver algum problema. Vamos destacar os problemas óbvios de automação de testes no contexto de testes de interface do usuário:
- uma enorme quantidade de dependências ao instalar Selenium e especialmente Appium;
- problemas de compatibilidade entre versões de navegadores, simuladores e drivers;
- falta de um espaço isolado para navegadores/simuladores, o que é especialmente crítico para a execução paralela;
- é difícil gerenciar e manter se for necessário executar 10, 50, 100 ou até mesmo 1000 navegadores ao mesmo tempo.
Mas como o Selenium é a ferramenta de automação mais popular e o Docker é a ferramenta de contêinerização mais popular, não deve ser surpresa que alguém tenha tentado combiná-los para obter uma poderosa ferramenta para resolver os problemas mencionados acima. Vamos examinar essas soluções mais detalhadamente.
Selenium grid em docker
Esta ferramenta é a mais popular do mundo Selenium para executar vários navegadores em várias máquinas e gerenciá-los a partir de um nó central. Para iniciar, é necessário registrar pelo menos 2 partes: Hub e Node(s). O Hub é o nó central que recebe todas as solicitações dos testes e as distribui para os Nodes correspondentes. Para cada Node, podemos configurar uma configuração específica, por exemplo, especificando o navegador necessário e sua versão. No entanto, ainda precisamos nos certificar de ter os drivers compatíveis para os navegadores e instalá-los nos Nodes necessários. Por essa razão, o Selenium Grid não é utilizado em sua forma pura, exceto em casos onde precisamos trabalhar com navegadores que não podem ser instalados no Linux OS. Para todos os outros casos, uma solução significativamente mais flexível e correta será o uso de imagens Docker para executar o Selenium Grid Hub e Nodes. Essa abordagem simplifica muito a gestão dos nós, uma vez que podemos escolher a imagem necessária com versões compatíveis de navegadores e drivers já instalados.
Apesar das críticas à estabilidade do funcionamento, especialmente ao executar um grande número de Nodes em paralelo, o Selenium Grid ainda permanece como a ferramenta mais popular para a execução paralela de testes Selenium. É importante notar que no open-source surgem continuamente várias melhorias e modificações desta ferramenta, que buscam resolver diferentes gargalos.
Selenoid para Web
Esta ferramenta é uma inovação no mundo do Selenium, pois funciona imediatamente e facilitou significativamente a vida de muitos engenheiros de automação. Antes de mais nada, não é mais uma modificação do Selenium Grid. Em vez disso, os desenvolvedores criaram uma nova versão do Selenium Hub na linguagem Golang, o que, em conjunto com imagens Docker leves para diferentes navegadores, deu um impulso ao desenvolvimento da automação de testes. Além disso, no caso do Selenium Grid, precisamos definir todos os navegadores e suas versões necessárias com antecedência, o que não é um problema quando se trabalha apenas com um único navegador. Mas quando se trata de vários navegadores suportados, o Selenoid é a solução número um, graças à função de 'navegador sob demanda'. Tudo o que precisamos fazer é carregar previamente as imagens necessárias dos navegadores e atualizar o arquivo de configuração que o Selenoid utiliza. Após receber uma solicitação dos testes, o Selenoid inicia automaticamente o contêiner com o navegador desejado. Quando o teste é concluído, o Selenoid descarta o contêiner, liberando assim os recursos para as próximas solicitações. Essa abordagem elimina completamente o conhecido problema da 'degradação dos nós', que frequentemente enfrentamos no Selenium Grid.
Mas, infelizmente, o Selenoid ainda não é a solução mágica. Obtivemos a função de 'navegador sob demanda', mas a função de 'recursos sob demanda' ainda não está disponível. Para usar o Selenoid, precisamos implantá-lo em hardware físico ou em uma VM, o que significa que precisamos saber com antecedência quantos recursos devem ser alocados. Acredito que isso não seja um problema para pequenos projetos que executam 10, 20 ou até 30 navegadores simultaneamente. Mas e se precisarmos de 100, 500, 1000 ou mais? Não faz sentido manter e pagar por essa quantidade de recursos constantemente. Nas seções 5 e 6 deste artigo, discutiremos soluções que permitem escalar, reduzindo significativamente os custos para a empresa.
Selenoid para Android
Após o sucesso do Selenoid como uma ferramenta para automação web, as pessoas queriam algo semelhante para Android. E isso aconteceu – o Selenoid foi lançado com suporte a Android. Do ponto de vista do usuário, o princípio de funcionamento é similar à automação web. A única diferença é que, em vez de containers com navegadores, o Selenoid inicia containers com emuladores Android. Na minha opinião, atualmente, essa é a ferramenta gratuita mais poderosa para executar testes Android em paralelo.
Eu realmente não gostaria de falar sobre os aspectos negativos dessa ferramenta, pois eu realmente gosto muito dela. Mas ainda assim, existem as mesmas desvantagens que se aplicam à automação web, relacionadas à escalabilidade. Além disso, é necessário mencionar outra limitação que pode ser uma surpresa se estivermos configurando a ferramenta pela primeira vez. Para executar imagens Android, precisamos de uma máquina física ou VM com suporte a virtualização aninhada. No guia prático, demonstro como ativá-lo em uma VM Linux. No entanto, se você é um usuário do macOS e deseja implantar o Selenoid localmente, a execução de testes Android será impossível. Mas você sempre pode iniciar uma VM Linux localmente com a 'virtualização aninhada' configurada e implantar o Selenoid por dentro.
Ilustração do estado atual da infraestrutura
No contexto deste artigo, adicionaremos 2 ferramentas para ilustrar a infraestrutura. Estes são o Selenium Grid para testes web e o Selenoid para testes Android. No guia no GitHub, também mostrarei como usar o Selenoid para executar testes web.
Links para estudo
Ferramentas semelhantes
- Existem outras ferramentas de containerização, mas o Docker é o mais popular. Se você quiser experimentar algo diferente, note que as ferramentas que discutimos para a execução paralela de testes Selenium não funcionarão automaticamente.
- Como já foi mencionado, existem muitas modificações do Selenium Grid, por exemplo,.
4. CI / CD
Breve descrição da tecnologia
A prática de integração contínua é bastante popular no desenvolvimento e ocupa um lugar ao lado dos sistemas de controle de versão. Apesar disso, sinto que há confusão na terminologia. Neste parágrafo, gostaria de descrever três modificações dessa tecnologia do meu ponto de vista. Na internet, você encontrará muitos artigos com diferentes interpretações, e isso é absolutamente normal se a sua opinião for diferente. O mais importante é que você esteja na mesma sintonia que seus colegas.
Então, existem três termos: CI — Continuous Integration (integração contínua), CD — Continuous Delivery (entrega contínua) e novamente CD — Continuous Deployment (desdobramento contínuo). (A partir de agora, usarei esses termos em inglês). Cada modificação adiciona algumas etapas adicionais ao seu pipeline de desenvolvimento. Mas a palavra continuous (contínua) é a mais importante. Nesse contexto, nos referimos a algo que acontece do início ao fim, sem interrupções ou intervenções manuais. Vamos olhar para CI & CD e CD nesse contexto.
- Continuous Integration – é o primeiro passo da evolução. Após o envio de um novo código ao servidor, esperamos receber um retorno rápido de que nossas alterações estão corretas. Geralmente, o CI envolve a execução de ferramentas de análise de código estático e testes de unidade/API internos. Isso permite receber informações sobre nosso código apenas alguns segundos/minutos depois.
- Continuous Delivery é um passo mais avançado, onde executamos testes de integração/UI. No entanto, neste estágio, não obtemos resultados tão rapidamente quanto no CI. Primeiro, esses tipos de testes levam mais tempo para serem concluídos. Em segundo lugar, antes de executar, precisamos implantar nossas alterações em um ambiente de teste/staging. Além disso, se estivermos falando sobre desenvolvimento móvel, haverá uma etapa adicional para criar a compilação do nosso aplicativo.
- Continuous Deployment significa que liberamos automaticamente nossas alterações em produção, se todos os testes de aceitação foram concluídos nas etapas anteriores. Além disso, após a etapa de liberação, várias fases podem ser configuradas, como a execução de testes smoke em produção e a coleta de métricas relevantes. Continuous Deployment é possível apenas com uma boa cobertura de testes automatizados. Se houver necessidade de intervenções manuais, incluindo testes, isso já não é mais Contínuo (continuous). Assim, podemos dizer que nosso pipeline se alinha apenas à prática de Continuous Delivery.
Valor para a infraestrutura de automação
Nesta seção, devo esclarecer que, quando falamos sobre testes de UI end-to-end, isso implica que devemos implantar nossas alterações e os serviços relacionados em ambientes de teste. Continuous Integration — processo que não se aplica a essa tarefa e precisamos nos certificar de integrar pelo menos as práticas de Continuous Delivery. Continuous Deployment também faz sentido no contexto de testes de UI, se planejamos executá-los em produção.
E antes de olharmos para a ilustração da mudança de 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 muitas outras funcionalidades adicionais. Portanto, o GitLab é mais que CI. Ele inclui, de forma nativa, gerenciamento de código-fonte, gerenciamento ágil, pipelines CI/CD, ferramentas de registro e coleta de métricas. A arquitetura do GitLab é composta pelo GitLab CI/CD e pelo GitLab Runner. Veja uma breve descrição do site oficial:
GitLab CI/CD é um aplicativo web com uma API que armazena seu estado em um banco de dados, gerencia projetos/construções e fornece uma interface de usuário. O GitLab Runner é um aplicativo que processa construções. Ele pode ser implantado separadamente e funciona com GitLab CI/CD através de uma API. Para a execução de testes, você precisa tanto da instância do GitLab quanto do Runner.
Ilustração do estado atual da infraestrutura
Links para estudo
Ferramentas semelhantes
- E muitos outros
5. Plataformas de nuvem
Breve descrição da tecnologia
Nesta seção, vamos falar sobre uma tendência popular chamada 'nuvens públicas'. Apesar dos enormes benefícios que as tecnologias de virtualização e conteinerização mencionadas acima oferecem, ainda precisamos de recursos computacionais. As empresas adquirem servidores caros ou alugam data centers, mas nesse caso, é necessário fazer cálculos (às vezes irrealistas) sobre quantos recursos precisaremos, se os utilizaremos 24/7 e para quais fins. Por exemplo, para produção, um servidor que funciona 24 horas por dia é necessário, mas precisamos de recursos semelhantes para testes fora do horário comercial? Isso também depende do tipo de teste realizado. Um exemplo pode ser testes de carga/estresse, que planejamos executar fora do horário comercial para obter resultados no dia seguinte. Mas, definitivamente, a disponibilidade contínua de servidores não é necessária para testes automatizados end-to-end e, especialmente, para ambientes de testes manuais. Para tais situações, seria ideal obter exatamente os recursos que precisamos sob demanda, utilizá-los e parar de pagar quando não forem mais necessários. Além disso, seria ótimo obtê-los instantaneamente, com alguns cliques do mouse ou rodando alguns scripts. É para isso que as nuvens públicas são usadas. Vamos dar uma olhada na definição:
«A nuvem pública é definida como serviços de computação oferecidos por provedores de terceiros pela Internet pública, tornando-os disponíveis para qualquer pessoa que queira usá-los ou comprá-los. Eles podem ser gratuitos ou vendidos sob demanda, permitindo que os clientes paguem apenas pelo uso dos ciclos de CPU, armazenamento ou largura de banda que consomem».
Há uma crença comum de que as nuvens públicas são caras. Mas sua ideia central é a redução das despesas da empresa. Como mencionado anteriormente, as nuvens públicas permitem obter recursos sob demanda e pagar apenas pelo tempo de uso. Além disso, às vezes esquecemos que os funcionários recebem salários e especialistas também são um recurso caro. É necessário considerar que as nuvens públicas facilitam significativamente o suporte à infraestrutura, permitindo que os engenheiros se concentrem em tarefas mais importantes.
Valor para a infraestrutura de automação
Quais recursos específicos precisamos para testes de UI end-to-end? Principalmente, são máquinas virtuais ou clusters (falaremos sobre Kubernetes na próxima seção) para executar navegadores e emuladores. Quanto mais navegadores e emuladores quisermos executar simultaneamente, mais CPU e memória serão necessários, e mais teremos que pagar por isso. Assim, as nuvens públicas no contexto da automação de testes nos permitem iniciar um grande número (100, 200, 1000 ...) de navegadores/emuladores sob demanda, obter resultados de testes o mais rápido possível e parar de pagar por essas capacidades absurdamente custosas.
Os provedores de nuvem mais populares são Amazon Web Services (AWS), Microsoft Azure e Google Cloud Platform (GCP). O guia prático apresenta exemplos de uso do GCP, mas, em geral, não importa o que você usará para tarefas de automação. Todos eles oferecem funcionalidades aproximadamente iguais. Normalmente, para escolher um provedor, o guia foca na infraestrutura da empresa e nos requisitos de negócios, que estão fora do escopo deste artigo. Para engenheiros de automação, será mais interessante comparar o uso de provedores de nuvem com o uso de plataformas de nuvem especificamente para fins de teste, como Sauce Labs, BrowserStack, BitBar e assim por diante. Então, vamos fazer isso! Na minha opinião, o Sauce Labs é a mais conhecida fazenda de testes em nuvem, então eu o escolhi para a comparação.
GCP versus Sauce Labs para fins de automação:
Suponha que precisamos executar simultaneamente 8 testes web e 8 testes Android. Para isso, usaremos o GCP e iniciaremos 2 máquinas virtuais com Selenoid. Na primeira, levantaremos 8 contêineres com navegadores. Na segunda – 8 contêineres com emuladores. Vamos dar uma olhada nos preços:
Para executar um contêiner com Chrome, precisaremos de n1-standard-1 máquina. No caso do Android, será n1-standard-4 para um emulador. Na verdade, uma maneira mais flexível e barata é definir valores personalizados específicos para CPU/Memory, mas neste momento, para comparação com o Sauce Labs, isso não é fundamental.
Aqui estão as tarifas para uso do Sauce Labs:
Eu suponho que você já notou a diferença, mas ainda assim, apresento uma tabela com os cálculos para a nossa tarefa:
Recursos necessários
Mensal
Horas de trabalho(8 a.m — 8 p.m)
Horas de trabalho+ Preemptivo
GCP para Web
n1-standard-1 x 8 = n1-standard-8
$194.18
23 dias * 12h * 0.38 = 104,88$
23 dias * 12h * 0.08 = 22,08$
Sauce Labs para Web
Testes paralelos em Virtual Cloud8
$1.559
—
—
GCP para Android
n1-standard-4 x 8: n1-standard-16
$776.72
23 dias * 12h * 1.52 = 419,52$
23 dias * 12h * 0.32 = 88,32$
Sauce Labs para Android
Testes em nuvem com dispositivos reais em 8 paralelos
$1.999
—
—
Como você pode ver, a diferença de custo é enorme, especialmente se os testes forem executados apenas no intervalo de doze horas úteis. Mas é possível reduzir ainda mais os custos se você usar máquinas preemptibles. O que é isso?
Uma VM preemptible é uma instância que você pode criar e executar a um preço muito menor do que as instâncias normais. No entanto, o Compute Engine pode encerrar (preempt) essas instâncias se precisar de acesso a esses recursos para outras tarefas. Instâncias preemptibles são a capacidade excedente do Compute Engine, portanto, sua disponibilidade varia com o uso.
Se seus aplicativos forem tolerantes a falhas e puderem suportar possíveis preempções de instância, então instâncias preemptibles podem reduzir significativamente seus custos com o Compute Engine. Por exemplo, trabalhos de processamento em lote podem ser executados em instâncias preemptibles. Se algumas dessas instâncias forem encerradas durante o processamento, o trabalho desacelera, mas não para completamente. Instâncias preemptibles completam suas tarefas de processamento em lote sem sobrecarregar suas instâncias existentes e sem exigir que você pague o preço cheio por instâncias normais adicionais.
E isso ainda não é tudo! Na verdade, estou certo de que ninguém executa testes por 12 horas ininterruptas. E se for assim, você pode iniciar e parar automaticamente as máquinas virtuais quando não são necessárias. O tempo real de uso pode ser reduzido para até 6 horas por dia. Nesse caso, o pagamento no contexto de nossa tarefa diminuiria para apenas 11$ por mês por 8 navegadores. Não é maravilhoso? Mas com máquinas preemptibles devemos ter cuidado e estar preparados para interrupções e funcionamento instável, embora essas situações possam ser previstas e tratadas programaticamente. Vale a pena!
Mas de forma alguma estou dizendo 'nunca use fazendas de testes em nuvem'. Elas têm uma série de benefícios. Antes de tudo, não se trata apenas de uma máquina virtual, mas de uma solução completa para automação de testes com um conjunto de funcionalidades prontas para uso: acesso remoto, registros, capturas de tela, gravação de vídeo, vários navegadores e dispositivos móveis físicos. Em muitas situações, isso pode ser uma alternativa luxuosa insubstituível. Especialmente plataformas de teste são úteis para automação de IOS, quando nuvens públicas podem oferecer apenas sistemas Linux/Windows. Mas a conversa sobre IOS ficará para os próximos artigos. Recomendo sempre considerar a situação e basear-se nas tarefas: em alguns casos é mais barato e eficaz usar nuvens públicas, enquanto em outros plataformas de teste definitivamente valem o investimento.
Ilustração do estado atual da infraestrutura
Links para estudo
Ferramentas Similares:
6. Orquestração
Breve descrição da tecnologia
Tenho boas notícias – estamos quase no final do artigo! Até agora, nossa infraestrutura de automação consiste em testes web e Android, que executamos através do GitLab CI em paralelo, utilizando ferramentas com suporte a Docker: Selenium grid e Selenoid. Além disso, utilizamos máquinas virtuais criadas através do GCP para levantar contêineres com navegadores e emuladores. Para reduzir custos, ativamos essas máquinas virtuais apenas sob demanda e as paramos quando os testes não estão em execução. Existe algo mais que possa melhorar nossa infraestrutura? A resposta é sim! Apresentamos o Kubernetes (K8s)!
Para começar, vamos considerar como as palavras orquestração, cluster e Kubernetes estão interligadas. Em um nível alto, orquestração é um sistema que implanta e gerencia aplicações. Para automação de testes, essas aplicações conteinerizáveis são o Selenium grid e o Selenoid. Docker e K8s se complementam. O primeiro é utilizado para implantar aplicações, enquanto o segundo é para orquestração. Por sua vez, K8s é um cluster. A função do cluster é usar VMs como Nodes, o que permite instalar diferentes funcionalidades, programas e serviços dentro de um único servidor (cluster). Se algum dos Nodes falhar, outros Nodes assumem, garantindo a operação ininterrupta da nossa aplicação. Além disso, K8s possui funcionalidades importantes relacionadas à escalabilidade, permitindo que automaticamente obtenhamos a quantidade ideal de recursos, com base na carga e nos limites estabelecidos.
Para ser sincero, configurar manualmente o Kubernetes do zero é uma tarefa bastante não trivial. Vou deixar um link para um famoso guia prático chamado "Kubernetes The Hard Way", e, se você estiver interessado, pode praticar. Mas, felizmente, existem maneiras e ferramentas alternativas. A mais fácil delas é usar o Google Kubernetes Engine (GKE) no GCP, o que permitirá obter um cluster pronto após alguns cliques. Para começar a estudar, recomendo usar essa abordagem, pois ela permitirá que você se concentre em aprender como usar o K8s para suas tarefas em vez de investigar como os componentes internos devem ser integrados entre si.
Valor para a infraestrutura de automação
Vamos examinar algumas funções significativas que o K8s oferece:
- implantação de aplicativos: uso de um cluster multi-nodes, em vez de VMs;
- escalonamento dinâmico: reduz os custos de recursos que são utilizados apenas sob demanda;
- auto-reparação (Self-healing): restauração automática de pods (o que restaura também os contêineres);
- implantações de atualizações e reversões sem interrupções: atualizar ferramentas, navegadores e emuladores não interrompe o trabalho dos usuários atuais.
Mas K8s ainda não é uma bala de prata. Para entender todos os benefícios e limitações no contexto das ferramentas que estamos discutindo (Selenium grid, Selenoid), vamos discutir brevemente a estrutura do K8s. O Cluster contém dois tipos de Nodes: Master Nodes e Workers Nodes. Os Master Nodes são responsáveis pela gestão, implantação e decisões de agendamento. Os Worker Nodes são onde os aplicativos estão em execução. Os Nodes também contêm o ambiente de execução dos contêineres. Neste caso, é o Docker, que cuida das operações relacionadas aos contêineres. Mas existem também soluções alternativas, como. É importante entender que o escalonamento ou auto-reparação não se aplica diretamente aos contêineres. Isso é realizado através da adição/remover o número de pods, que por sua vez contêm contêineres (geralmente um contêiner por pod, mas dependendo da tarefa, pode haver mais). A hierarquia de alto nível consiste em worker nodes, dentro dos quais estão os pods, dentro dos quais estão os contêineres.
A funcionalidade de escalonamento é fundamental e pode ser aplicada tanto a nodes dentro do node-pool de cluster quanto a pods dentro do node. Existem 2 tipos de escalonamento, que se aplicam tanto a nodes quanto a pods. O primeiro tipo – horizontal – o escalonamento ocorre por meio do aumento do número de nodes/pods. Este tipo é preferível. O segundo tipo, respectivamente, é vertical. O escalonamento é realizado aumentando os tamanhos de nodes/pods, e não sua quantidade.
Agora vamos considerar nossas ferramentas no contexto dos termos mencionados acima.
Selenium grid
Como mencionado anteriormente, o Selenium grid é uma ferramenta muito popular, e não é surpresa que tenha sido containerizado. Portanto, não é surpreendente que o Selenium grid possa ser implantado no K8s. Um exemplo de como fazer isso pode ser encontrado no repositório oficial do K8s. Como de costume, coloco os links no final da seção. Além disso, o guia prático mostra como fazer isso usando o Terraform. Também há instruções sobre como escalar o número de pods que contêm contêineres com navegadores. Mas a funcionalidade de escalonamento automático no contexto do K8s ainda é uma tarefa não completamente compreendida. Quando comecei meu estudo, não encontrei nenhum guia prático ou recomendações. Após várias pesquisas e experimentos com o apoio da equipe de DevOps, escolhemos a abordagem de levantar contêineres com os navegadores necessários dentro de um pod, que está dentro de um worker node. Essa abordagem nos permite aplicar a estratégia de escalonamento horizontal de nodes por meio do aumento de seu número. Espero que, no futuro, a situação mude e vejamos cada vez mais descrições das melhores abordagens e soluções prontas, especialmente após o lançamento do Selenium grid 4 com a arquitetura interna alterada.
Selenoid:
Atualmente, a implantação do Selenoid no K8s é a maior decepção. Eles não são compatíveis. Teoricamente, podemos levantar um contêiner do Selenoid dentro de um pod, mas quando o Selenoid começar a executar contêineres com navegadores, eles ainda estarão dentro do mesmo pod. Isso torna o escalonamento impossível e, como resultado, o funcionamento do Selenoid dentro do cluster não será diferente do funcionamento dentro de uma máquina virtual. Fim da história.
Moon:
Sabendo disso, ao trabalhar com o Selenoid, os desenvolvedores lançaram uma ferramenta mais poderosa chamada Moon. Esta ferramenta foi inicialmente projetada para funcionar com Kubernetes e, como resultado, a função de autoescalonamento pode e deve ser utilizada. Além disso, eu diria que no momento atual, isso única é a ferramenta no mundo do Selenium que, por padrão, possui suporte nativo a clusters K8s (não mais, veja a próxima ferramenta ). A característica chave do Moon, que proporciona esse suporte, é:
Completamente sem estado. O Selenoid armazena em memória informações sobre as sessões de navegador em execução. Se por algum motivo seu processo falhar, todas as sessões em execução são perdidas. O Moon, ao contrário, não tem estado interno e pode ser replicado entre os centros de dados. As sessões de navegador permanecem ativas mesmo se uma ou mais réplicas falharem.
Então, o Moon é uma solução incrível, mas tem um problema: não é gratuito. O preço depende do número de sessões. É possível executar apenas 0-4 sessões gratuitamente, o que não é muito útil. A partir da quinta sessão, será necessário pagar 5$ por cada uma. A situação pode variar de empresa para empresa, mas no nosso caso, usar o Moon não faz sentido. Como mencionei acima, podemos iniciar VMs com Selenium Grid sob demanda ou aumentar o número de Nodes no cluster. Aproximadamente em um pipeline, iniciamos 500 navegadores e desligamos todos os recursos após a conclusão dos testes. Se estivéssemos usando o Moon, teríamos que pagar um adicional de 500 x 5 = 2500 $ por mês, independentemente da frequência com que executamos os testes. E novamente, não estou dizendo 'não use o Moon'. Para suas necessidades, pode ser uma solução indispensável, por exemplo, se você tiver muitos projetos/equipes na sua organização e precisar de um enorme cluster compartilhado 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 mencionei, o Selenium é uma ferramenta muito popular, e a área de TI está se desenvolvendo rapidamente. Enquanto trabalhei na tradução, uma nova ferramenta promissora chamada Callisto apareceu na rede (saudações ao Cypress e outros concorrentes do Selenium). Ela funciona nativamente com K8s e permite a execução de contêineres Selenoid em pods, distribuídos por Nodes. Tudo funciona imediatamente, incluindo a autoescala. Fantástico, mas é necessário testar. Já consegui implementar essa ferramenta e realizar alguns experimentos. Mas ainda é cedo para tirar conclusões; após obter resultados a longo prazo, talvez eu crie uma revisão em próximos artigos. Por enquanto, deixo apenas links para pesquisas independentes.
Ilustração do estado atual da infraestrutura
Links para estudo
Links para estudo
Ferramentas semelhantes
7. Infraestrutura como Código (IaC)
Breve descrição da tecnologia
E aqui chegamos à última seção. Normalmente, essa tecnologia e as tarefas relacionadas não estão sob a responsabilidade dos engenheiros de automação. E há razões para isso. Primeiro, em muitas organizações, questões de infraestrutura estão sob o controle do departamento de DevOps e a equipe de desenvolvimento não se preocupa muito com o que faz o pipeline funcionar e como manter tudo o que está relacionado a isso. Em segundo lugar, sejamos honestos, a prática "Infraestrutura como Código (IaC)" ainda não é aplicada em muitas empresas. Mas definitivamente isso se tornou uma tendência popular e é importante tentar estar envolvido nos processos, abordagens e ferramentas relacionadas. Ou, pelo menos, estar ciente dos eventos.
Comecemos pela motivação para usar essa abordagem. Já discutimos que, para executar testes no GitlabCI, precisaremos, no mínimo, de recursos para iniciar o Gitlab Runner. E para executar contêineres com navegadores/emuladores, precisamos reservar uma VM ou um cluster. Além dos recursos para testes, também precisamos de uma quantidade significativa de capacidade para manter os ambientes de desenvolvimento, staging e produção, o que inclui bancos de dados, cronogramas automáticos, configurações de rede, balanceadores de carga, permissões de usuários e assim por diante. O problema chave reside nos esforços necessários para manter tudo isso. Existem várias maneiras de como podemos fazer mudanças e implantar atualizações. Por exemplo, no contexto do GCP, podemos usar o console UI no navegador e realizar todas as ações clicando em botões. Uma alternativa pode ser usar chamadas de API para interagir com entidades na nuvem ou aplicar a ferramenta de linha de comando gcloud para realizar as manipulações necessárias. Mas, com uma quantidade realmente grande de diferentes entidades e elementos de infraestrutura, torna-se difícil ou até impossível realizar todas as operações manualmente. Além disso, todas essas ações manuais são incontroláveis. Não podemos enviá-las para revisão antes de executar, usar um sistema de controle de versões e reverter rapidamente alterações que levaram a um incidente. Para resolver tais problemas, engenheiros criaram e ainda criam scripts automáticos em bash/shell, que não são muito melhores do que os métodos anteriores, pois não são tão fáceis de ler, entender, manter e modificar rapidamente em um estilo procedural.
Neste artigo e guia prático, utilizo 2 ferramentas relacionadas à prática de IaC. São elas Terraform e Ansible. Alguns acreditam que não faz sentido usar ambas ao mesmo tempo, pois suas funcionalidades são semelhantes e elas são intercambiáveis. No entanto, o fato é que, inicialmente, elas são projetadas para tarefas completamente diferentes. E o fato de que essas ferramentas devem se complementar foi confirmado em uma apresentação conjunta pelos desenvolvedores das empresas 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ções, cuja tarefa é instalar, configurar e gerenciar o software nesses servidores.
Outra característica distintiva importante dessas ferramentas é o estilo de escrita do código. Ao contrário do bash e do Ansible, o Terraform utiliza um estilo declarativo, baseado na descrição do estado final desejado a ser alcançado como resultado da execução. Por exemplo, se quisermos criar 10 VMs e aplicar as mudanças através do Terraform, obteremos 10 VMs. Se executarmos o script novamente, nada acontecerá, pois já temos 10 VMs, e o Terraform sabe disso, uma vez que ele armazena o estado atual da infraestrutura em um arquivo de estado. Já o Ansible utiliza uma abordagem procedural e, se pedirmos para criar 10 VMs, na primeira execução obteremos 10 VMs, semelhante ao Terraform. Porém, após a segunda execução, teremos 20 VMs. Essa é a importante diferença. No estilo procedural, não armazenamos o estado atual e apenas descrevemos a sequência de etapas que devem ser executadas. Naturalmente, podemos lidar com várias situações, adicionar algumas verificações sobre a existência de recursos e o estado atual, mas não faz sentido desperdiçar nosso tempo e esforço controlando essa lógica. Além disso, isso aumenta o risco de cometer erros.
Resumindo tudo o que foi dito acima, podemos concluir que, para o provisionamento de servidores, a ferramenta mais adequada é o Terraform e a notação declarativa. Já o trabalho de gerenciamento de configurações é melhor delegado ao Ansible. Com isso esclarecido, vamos ver exemplos de uso no contexto da automação.
Valor para a infraestrutura de automação
Aqui, é importante entender que a infraestrutura de automação de testes 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 de seus processos. A equipe de DevOps tem mais experiência nesses assuntos, pois ela vê o quadro geral. No entanto, os engenheiros de QA estão mais envolvidos no processo de construção da automação e na estrutura do pipeline, o que lhes permite perceber melhor todas as mudanças necessárias e oportunidades de melhoria. A melhor opção é trabalhar em conjunto, trocando conhecimentos e ideias para alcançar o resultado esperado.
Vou dar alguns exemplos de uso do Terraform e Ansible no contexto de automação de testes e das ferramentas que discutimos anteriormente:
1. Descrever, através do Terraform, as características e parâmetros necessários para VMs e clusters.
2. Instalar, com o Ansible, as ferramentas necessárias para testes: docker, Selenoid, Selenium Grid e baixar as versões necessárias de navegadores/emuladores.
3. Descrever, através do Terraform, as características da VM onde o GitLab Runner será executado.
4. Instalar, com o Ansible, o GitLab Runner e as ferramentas auxiliares necessárias, definindo as configurações e ajustes.
Ilustração do estado atual da infraestrutura
Links para estudo:
Ferramentas semelhantes
Resumindo!
Passo
Tecnologia
Ferramentas
Valor para a infraestrutura de automação
1
Execução local
Node.js, Selenium, Appium
- As ferramentas mais populares para web e mobile
- Suporte a várias linguagens e plataformas (incluindo Node.js)
2
Sistemas de controle de versão
Git
- Vantagens semelhantes com o código de desenvolvimento
3
Contêinerização
Docker, grid do Selenium, Selenoid (Web, Android)
- Execução paralela de testes
- Ambientes isolados
- Atualização de versões simples e flexível
- Parada dinâmica de recursos não utilizados
- Fácil de configurar
4
CI / CD
Gitlab CI
- Testes como parte do pipeline
- Feedback rápido
- Visibilidade para toda a empresa/equipe
5
Plataformas em nuvem
Google Cloud Platform
- Recursos sob demanda (pagamos apenas quando precisamos)
- Fácil de gerenciar e atualizar
- Visibilidade e controle de todos os recursos
6
Orquestração
Kubernetes
No contexto de contêineres com navegadores/emuladores dentro dos pods:
- Escalonamento / autoescalonamento
- Autorreparo
- Atualizações e retrocessos sem interrupções
7
Infraestrutura como código (IaC)
Terraform, Ansible
- Vantagens semelhantes com a infraestrutura de desenvolvimento
- Todas as vantagens de versionamento de código
- Fácil de fazer mudanças e manter
- Totalmente automatizado
Diagramas de mapas mentais: a evolução da infraestrutura
etapa1: Local
etapa2: VCS
etapa3: Containerização
etapa4: CI/CD
etapa5: Plataformas em Nuvem
etapa6: Orquestração
etapa7: IaC
E agora?
Então, este é o fim do artigo. Mas, para concluir, gostaria de estabelecer alguns acordos com você.
Da sua parte
Como mencionado no início, gostaria que o artigo fosse de utilidade prática e ajudasse você a aplicar os conhecimentos adquiridos no trabalho real. Adiciono novamente.
Mas mesmo depois disso, não pare, pratique, estude os links e livros relevantes, descubra como isso funciona em sua empresa, encontre áreas que podem ser melhoradas e participe disso. Boa sorte!
Da minha parte
Do título, fica claro que esta foi apenas a primeira parte. Embora tenha ficado bastante longa, ainda há tópicos importantes a serem discutidos. Na segunda parte, planejo abordar a infraestrutura de automação no contexto do IOS. Devido a restrições da Apple relacionadas ao lançamento de simuladores de IOS apenas em sistemas macOS, nosso conjunto de soluções é limitado. Por exemplo, não podemos usar Docker para executar o simulador ou nuvens públicas para executar máquinas virtuais. Mas isso não significa que não existam outras alternativas. Tentarei mantê-lo informado sobre soluções de ponta e ferramentas modernas!
Além disso, não mencionei os temas bastante amplos relacionados ao monitoramento. Na parte 3, planejo discutir as ferramentas mais populares para monitorar a infraestrutura, assim como quais dados e métricas devem ser considerados.
E, por último. No futuro, pretendo lançar um curso em vídeo sobre como construir uma infraestrutura de teste e ferramentas populares. Atualmente, há muitos cursos e palestras sobre DevOps na internet, mas todo o material é apresentado no contexto do desenvolvimento, não da automação de testes. Nesse aspecto, preciso muito do feedback sobre se tal curso seria interessante e valioso para a comunidade de testadores e automatizadores. Agradeço antecipadamente!
Fonte: habr.com
