Parte 1: Web/Android
Nota: este artigo é uma tradução para o russo do artigo original No entanto, todas as ilustrações, links, citações e termos são preservados no idioma original para evitar distorção de significado quando traduzidos para o russo. Desejo-lhe bons estudos!
Atualmente, a especialidade DevOps é uma das mais procuradas na indústria de TI. Se você abrir sites populares de busca de empregos e filtrar por salário, verá que os empregos relacionados ao DevOps estão no topo da lista. No entanto, é importante compreender que se trata principalmente de uma posição 'Sénior', o que implica que o candidato possua um elevado nível de competências, conhecimentos de tecnologia e ferramentas. Isto também acarreta um alto grau de responsabilidade associado à operação ininterrupta da produção. No entanto, começamos a esquecer o que é DevOps. Inicialmente, não era nenhuma pessoa ou departamento específico. Se procurarmos definições deste termo, encontraremos 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 (engenheiro de automação de QA), mas acredito que ela não deve estar associada apenas à escrita de autotestes ou ao desenvolvimento de arquitetura de framework de testes. Em 2020, o conhecimento da infraestrutura de automação também é essencial. Isso permite que você mesmo organize o processo de automação, desde a execução de testes até o fornecimento de resultados a todos os stakeholders de acordo com seus objetivos. Como resultado, as habilidades de DevOps são essenciais para realizar o trabalho. E tudo isso é bom, mas, infelizmente, tem um problema (spoiler: este artigo tenta simplificar este problema). A questão é que DevOps é difícil. E isso é óbvio, porque as empresas não pagarão muito por algo que é fácil de fazer... No mundo DevOps, há um grande número de ferramentas, termos e práticas que precisam ser dominadas. Isto é especialmente difícil no início da carreira e depende da experiência técnica acumulada.
Fonte:
Aqui provavelmente terminaremos com 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 de automação de testes. Existem muitas fontes de informação na Internet sobre diversas ferramentas e como usá-las, mas eu gostaria de analisá-las puramente no contexto da automação. Acredito que muitos engenheiros de automação estão familiarizados com a situação em que ninguém, exceto você, executa os testes desenvolvidos ou se preocupa em mantê-los. Como resultado, os testes ficam desatualizados e você precisa gastar tempo atualizando-os. Novamente, no início de uma carreira, esta pode ser uma tarefa bastante difícil: decidir sabiamente quais ferramentas devem ajudar a eliminar um determinado problema, como selecioná-las, configurá-las e mantê-las. Alguns testadores recorrem ao DevOps (humanos) em busca de ajuda e, sejamos honestos, essa abordagem funciona. Em muitos casos esta pode ser a única opção já que não temos visibilidade de todas as dependências. Mas como sabemos, DevOps são caras muito ocupados, pois têm que pensar em toda a infraestrutura da empresa, implantação, monitoramento, microsserviços e outras tarefas semelhantes dependendo da organização/equipe. Como normalmente acontece, a automação não é uma prioridade. Nesse caso, devemos tentar fazer todo o possível da nossa parte, do início ao fim. Isso reduzirá dependências, acelerará o fluxo de trabalho, melhorará nossas habilidades e nos permitirá ter uma visão geral do que está acontecendo.
O artigo apresenta as ferramentas mais populares e populares e mostra passo a passo como usá-las para construir uma infraestrutura de automação. Cada grupo é representado por ferramentas que foram testadas através da experiência pessoal. Mas isso não significa que você tenha que usar a mesma coisa. As ferramentas em si não são importantes, elas aparecem e se tornam obsoletas. Nossa tarefa de engenharia é compreender os princípios básicos: por que precisamos desse grupo de ferramentas e quais problemas de trabalho podemos resolver com a ajuda deles. É por isso que no final de cada seção deixo links para ferramentas semelhantes que podem ser utilizadas na sua organização.
O que não está neste artigo
Repito mais uma vez que o artigo não trata de ferramentas específicas, portanto não haverá inserções de código da documentação e descrições de comandos específicos. Mas no final de cada seção deixo links para estudo detalhado.
Isso é feito porque:
- este material é muito fácil de encontrar em diversas fontes (documentação, livros, videoaulas);
- se começarmos a nos aprofundar, teremos que escrever 10, 20, 30 partes deste artigo (enquanto os planos são 2-3);
- Só não quero desperdiçar seu tempo, pois você pode querer usar outras ferramentas para atingir os mesmos objetivos.
Prática
Eu realmente gostaria que este material fosse útil para todos os leitores, e não apenas lido e esquecido. Em qualquer estudo, a prática é um componente muito importante. Para isso eu preparei. Também há lição de casa esperando por você para garantir que você não copie inconscientemente as linhas dos comandos que está executando.
Plano
Passo
Equipar
Ferramentas
1
Execução local (preparar testes de demonstração web/Android e executá-los localmente)
Node.js, Selênio, Appium
2
Sistemas de controle de versão
Git
3
Conteinerização
Docker, grade Selenium, Selenoid (Web, Android)
4
CI/CD
CI do Gitlab
5
Plataformas de 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 clara, cada seção é descrita de acordo com o seguinte esquema:
- breve descrição da tecnologia,
- valor para infraestrutura de automação,
- ilustração do estado atual da infraestrutura,
- links para estudar,
- ferramentas semelhantes.
1. Execute testes localmente
Breve descrição da tecnologia
Esta é apenas uma etapa preparatória para executar os testes de demonstração localmente e verificar se eles foram aprovados. Na parte prática é utilizado Node.js, mas a linguagem de programação e plataforma também não são importantes e você pode utilizar aquelas que são utilizadas na sua empresa.
Porém, como ferramentas de automação, recomendo utilizar Selenium WebDriver para plataformas web e Appium para plataforma Android, respectivamente, pois nos próximos passos utilizaremos imagens Docker que são adaptadas para funcionar especificamente com essas ferramentas. Além disso, referindo-se às exigências do trabalho, essas ferramentas são as mais procuradas no mercado.
Como você deve ter notado, consideramos apenas testes web e Android. Infelizmente, o iOS é uma história completamente diferente (obrigado Apple). Pretendo mostrar soluções e práticas relacionadas ao IOS nas próximas partes.
Valor para infraestrutura de automação
Do ponto de vista da infraestrutura, a execução local não traz 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 para explorar
Ferramentas semelhantes
- qualquer linguagem de programação de sua preferência em conjunto com testes Selenium/Appium;
- quaisquer testes;
- qualquer executor de teste.
2. Sistemas de controle de versão (Git)
Breve descrição da tecnologia
Não será uma grande revelação para ninguém se eu disser que o controle de versão é uma parte extremamente importante do desenvolvimento, tanto em equipe quanto individualmente. Com base em várias fontes, é seguro dizer que o Git é o representante mais popular. Um sistema de controle de versão oferece muitos benefícios, como compartilhamento de código, armazenamento de versões, restauração de ramificações anteriores, monitoramento do histórico do projeto e backups. Não discutiremos cada ponto detalhadamente, pois tenho certeza que você o conhece bem e o utiliza no seu trabalho diário. Mas se de repente não, recomendo fazer uma pausa na 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 está nos contando sobre o Git? Todo mundo sabe disso e usa isso tanto para código de desenvolvimento quanto para código de teste automático.” Você terá toda razão, mas neste artigo estamos falando sobre infraestrutura e esta seção funciona como uma prévia da seção 7: “Infraestrutura como Código (IaC)”. Para nós, isso significa que toda a infraestrutura, incluindo os testes, é descrita na forma de código, para que também possamos aplicar sistemas de versionamento a ela e obter benefícios semelhantes aos do 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á ampliado quando adicionarmos um repositório remoto à infraestrutura.
Ilustração do estado atual da infraestrutura
Links para explorar
Ferramentas semelhantes
3. Conteinerização (Docker)
Breve descrição da tecnologia
Para demonstrar como a conteinerização mudou as regras do jogo, vamos voltar algumas décadas no tempo. Naquela época, as pessoas compravam e usavam máquinas servidoras para executar aplicativos. Mas na maioria dos casos, os recursos iniciais necessários não eram conhecidos antecipadamente. Como resultado, as empresas gastaram dinheiro na compra de servidores caros e poderosos, mas parte dessa capacidade não foi totalmente utilizada.
O próximo estágio de evolução foram as máquinas virtuais (VMs), que resolveram o problema de desperdício de dinheiro em recursos não utilizados. Essa tecnologia possibilitou a execução de aplicações de forma independente dentro de um mesmo servidor, alocando espaços totalmente isolados. 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, os custos de licença precisam ser levados em consideração. Esses fatores afetam a velocidade de carregamento e dificultam a portabilidade.
E agora chegamos à conteinerização. Mais uma vez, esta tecnologia resolve o problema anterior, pois os containers não utilizam um SO completo, o que libera uma grande quantidade de recursos e fornece uma solução rápida e flexível para portabilidade.
É claro que a tecnologia de conteinerização não é novidade e foi introduzida pela primeira vez no final dos anos 70. Naquela época, muitas pesquisas, desenvolvimentos e tentativas foram realizadas. Mas foi o Docker quem adaptou essa tecnologia e a tornou facilmente acessível às massas. Hoje em dia, quando falamos em containers, na maioria dos casos nos referimos a Docker. Quando falamos sobre contêineres Docker, queremos dizer contêineres Linux. Podemos utilizar sistemas Windows e macOS para executar containers, mas é importante entender que neste caso aparece uma camada adicional. Por exemplo, o Docker no Mac executa contêineres silenciosamente dentro de uma VM Linux leve. Voltaremos a este tópico quando discutirmos a execução de emuladores Android dentro de contêineres, portanto, aqui há uma nuance muito importante que precisa ser discutida 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 toda ferramenta ou tecnologia precisa resolver um problema. Vamos delinear os problemas óbvios da automação de testes no contexto de testes de UI:
- um grande número de dependências ao instalar o Selenium e principalmente 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 execução paralela;
- difícil de 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 conteinerização mais popular, não deve ser surpresa que alguém tenha tentado combiná-los para criar uma ferramenta poderosa para resolver os problemas mencionados acima. Vamos considerar essas soluções com mais detalhes.
Grade de selênio na janela de encaixe
Esta ferramenta é a mais popular no mundo Selenium para executar vários navegadores em várias máquinas e gerenciá-los a partir de um hub central. Para começar, você precisa registrar pelo menos 2 partes: Hub e Nó(s). Hub é um nó central que recebe todas as solicitações de testes e as distribui para os nós apropriados. Para cada Node podemos definir uma configuração específica, por exemplo, especificando o navegador desejado e sua versão. No entanto, ainda precisamos cuidar dos drivers de navegador compatíveis e instalá-los nos nós desejados. Por este motivo, o Selenium grid não é utilizado 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, uma solução significativamente flexível e correta seria usar imagens Docker para executar hubs e nós da grade Selenium. Essa abordagem simplifica muito o gerenciamento de nós, pois podemos selecionar a imagem que precisamos com versões compatíveis de navegadores e drivers já instalados.
Apesar das críticas negativas sobre estabilidade, especialmente ao executar um grande número de nós em paralelo, a grade Selenium ainda é a ferramenta mais popular para executar testes Selenium em paralelo. É importante ressaltar que diversas melhorias e modificações desta ferramenta aparecem constantemente em código aberto, o que combate diversos gargalos.
Selenóide para Web
Esta ferramenta é uma inovação no mundo do Selenium, pois funciona imediatamente e tornou a vida de muitos engenheiros de automação muito mais fácil. Em primeiro lugar, esta não é outra modificação da grade Selenium. Em vez disso, os desenvolvedores criaram uma versão completamente nova do Selenium Hub em Golang, que, combinada com imagens leves do Docker para vários navegadores, deu impulso ao desenvolvimento da automação de testes. Além disso, no caso do Selenium Grid, devemos determinar antecipadamente todos os navegadores necessários e suas versões, o que não é um problema quando se trabalha com apenas um navegador. Mas quando se trata de vários navegadores suportados, o Selenoid é a solução número um graças ao seu recurso ‘navegador sob demanda’. Tudo o que nos é exigido é baixar previamente as imagens necessárias dos navegadores e atualizar o arquivo de configuração com o qual o Selenoid interage. Após o Selenoid receber uma solicitação dos testes, ele iniciará automaticamente o contêiner desejado com o navegador desejado. Quando o teste for concluído, o Selenoid retirará o contêiner, liberando recursos para solicitações futuras. Esta abordagem elimina completamente o conhecido problema de “degradação de nós” que frequentemente encontramos na grade Selenium.
Mas, infelizmente, o Selenoid ainda não é uma solução mágica. Obtivemos o recurso ‘navegador sob demanda’, mas o recurso ‘recursos sob demanda’ ainda não está disponível. Para usar o Selenoid, devemos implantá-lo em hardware físico ou em uma VM, o que significa que devemos saber antecipadamente quantos recursos precisam ser alocados. Acho que isso não é um problema para projetos pequenos que executam 10, 20 ou até 30 navegadores em paralelo. Mas e se precisarmos de 100, 500, 1000 ou 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.
Selenóide para Android
Após o sucesso do Selenoid como ferramenta de automação web, as pessoas queriam algo semelhante para 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 ao da automação web. A única diferença é que, em vez de contêineres de navegador, o Selenoid executa contêineres de emulador Android. Na minha opinião, esta é atualmente a ferramenta gratuita mais poderosa para executar testes Android em paralelo.
Eu realmente não gostaria de falar sobre os aspectos negativos desta ferramenta, pois gosto muito dela. Mesmo assim, existem as mesmas desvantagens que se aplicam à automação da web e estão associadas ao escalonamento. Além disso, precisamos falar sobre mais uma limitação que pode nos surpreender se estivermos configurando a ferramenta pela primeira vez. Para executar imagens Android, precisamos de uma máquina física ou VM com suporte para virtualização aninhada. No guia prático, demonstro como habilitar isso em uma VM Linux. No entanto, se você for um usuário macOS e quiser implantar o Selenoid localmente, não será possível executar testes do Android. Mas você sempre pode executar uma VM Linux localmente com a 'virtualização aninhada' configurada e implantar o Selenoid dentro dela.
Ilustração do estado atual da infraestrutura
No contexto deste artigo, adicionaremos 2 ferramentas para ilustrar a infraestrutura. Estes são a grade Selenium para testes da web e o Selenoid para testes do Android. No tutorial do GitHub, também mostrarei como usar o Selenoid para executar testes web.
Links para explorar
Ferramentas semelhantes
- 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 abordamos para executar testes do Selenium em paralelo não funcionarão imediatamente.
- Como já foi dito, existem muitas modificações na grade Selenium, por exemplo,.
4.CI/CD
Breve descrição da tecnologia
A prática de integração contínua é bastante popular no desenvolvimento e está no mesmo nível dos sistemas de controle de versão. Apesar disso, sinto que há confusão na terminologia. Neste parágrafo gostaria de descrever 3 modificações desta tecnologia do meu ponto de vista. Na internet você encontrará muitos artigos com interpretações diferentes, e é absolutamente normal que sua opinião seja diferente. O mais importante é que você esteja na mesma página que seus colegas.
Portanto, existem 3 termos: CI – Integração Contínua, CD – Entrega Contínua e novamente CD – Implantação Contínua. (Abaixo usarei esses termos em inglês). Cada modificação adiciona várias etapas adicionais ao seu pipeline de desenvolvimento. Mas a palavra contínuo (contínuo) é a coisa mais importante. Neste contexto, queremos dizer algo que acontece do início ao fim, sem interrupção ou intervenção manual. Vejamos CI & CD e CD neste contexto.
- Integração contínua este é o passo inicial da evolução. Depois de enviar o novo código ao servidor, esperamos receber um feedback rápido de que nossas alterações estão corretas. Normalmente, CI inclui a execução de ferramentas de análise de código estático e testes unitários/internos de API. Isso nos permite obter informações sobre nosso código em poucos segundos/minutos.
- Entrega Contínua é uma etapa mais avançada onde executamos testes de integração/UI. Contudo, nesta fase não obtemos resultados tão rapidamente como com o CI. Primeiro, esses tipos de testes demoram mais para serem concluídos. Em segundo lugar, antes do lançamento, devemos implantar nossas alterações no ambiente de teste/preparação. Além disso, se estamos falando de desenvolvimento móvel, surge uma etapa adicional para criar uma compilação de nosso aplicativo.
- Entrega Contínua assume que liberaremos automaticamente nossas alterações para produção se todos os testes de aceitação tiverem sido aprovados nas etapas anteriores. Além disso, após a fase de lançamento, é possível configurar diversas etapas, como execução de testes de fumaça em produção e coleta de métricas de interesse. A implantação contínua só é possível com boa cobertura de testes automatizados. Se forem necessárias quaisquer intervenções manuais, incluindo testes, isso não será mais necessário. Contínuo (contínuo). Então podemos dizer que nosso pipeline atende apenas à prática de Entrega Contínua.
Valor para infraestrutura de automação
Nesta seção, devo esclarecer que quando falamos sobre testes de UI ponta a ponta, isso significa que devemos implantar nossas mudanças e serviços associados em ambientes de teste. Integração Contínua - o processo não é aplicável para esta tarefa e devemos ter o cuidado de implementar pelo menos práticas de Entrega Contínua. A implantação contínua também faz sentido no contexto de testes de UI, se quisermos 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 muitos outros recursos adicionais. Assim, o GitLab é mais que CI. Inclui gerenciamento de código-fonte, gerenciamento ágil, pipelines de CI/CD, ferramentas de registro e coleta de métricas prontas para uso. A arquitetura GitLab consiste em Gitlab CI/CD e GitLab Runner. Aqui está uma breve descrição do site oficial:
Gitlab CI/CD é uma aplicação web com uma API que armazena seu estado em um banco de dados, gerencia projetos/construções e fornece uma interface de usuário. GitLab Runner é um aplicativo que processa compilações. Ele pode ser implantado separadamente e funciona com GitLab CI/CD por meio de uma API. Para testes em execução, você precisa da instância do Gitlab e do Runner.
Ilustração do estado atual da infraestrutura
Links para explorar
Ferramentas semelhantes
- E muitos outros
5. Plataformas em nuvem
Breve descrição da tecnologia
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 conteinerização descritas acima proporcionam, ainda precisamos de recursos computacionais. As empresas adquirem servidores caros ou alugam data centers, mas neste caso é necessário fazer cálculos (às vezes irrealistas) de quantos recursos precisaremos, se iremos utilizá-los 24 horas por dia, 7 dias por semana e para quais finalidades. Por exemplo, a produção requer um servidor funcionando XNUMX horas por dia, XNUMX dias por semana, mas precisamos de recursos semelhantes para testes fora do horário de trabalho? Também depende do tipo de teste que está sendo realizado. Um exemplo seriam os testes de carga/estresse que planejamos executar fora do horário comercial para obter resultados no dia seguinte. Mas definitivamente a disponibilidade do servidor XNUMX horas por dia, XNUMX dias por semana não é necessária para testes automatizados de ponta a ponta e especialmente para ambientes de teste manuais. Para tais situações, seria bom obter quantos recursos forem necessários sob demanda, utilizá-los e parar de pagar quando não forem mais necessários. Além disso, seria ótimo recebê-los instantaneamente com alguns cliques do mouse ou executando alguns scripts. É para isso que as nuvens públicas são usadas. Vejamos a definição:
“A nuvem pública é definida como serviços de computação oferecidos por provedores terceirizados através da Internet pública, disponibilizando-os para qualquer pessoa que queira utilizá-los ou adquiri-los. Eles podem ser gratuitos ou vendidos sob demanda, permitindo que os clientes paguem apenas por uso dos ciclos de CPU, armazenamento ou largura de banda que consomem."
Existe uma opinião de que as nuvens públicas são caras. Mas a ideia principal é reduzir os custos da empresa. Conforme mencionado anteriormente, as nuvens públicas permitem que você obtenha recursos sob demanda e pague apenas pelo tempo de uso. Além disso, às vezes esquecemos que os funcionários recebem salários e que os especialistas também são um recurso caro. Deve-se levar em conta que as nuvens públicas facilitam muito o suporte à infraestrutura, o que permite que os engenheiros se concentrem em tarefas mais importantes.
Valor para infraestrutura de automação
De quais recursos específicos precisamos para testes de IU de ponta a ponta? Basicamente, 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 rodar simultaneamente, mais CPU e memória serão necessárias e mais dinheiro teremos para pagar por isso. Assim, as nuvens públicas no contexto da automação de testes nos permitem executar 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 programas tão insanamente intensivos em recursos. poder.
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 como usar o GCP, mas em geral não importa o que você usa para tarefas de automação. Todos eles fornecem aproximadamente a mesma funcionalidade. Normalmente, para selecionar um fornecedor, a gestão concentra-se na infraestrutura geral e nos requisitos de negócios da empresa, o que está além 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 específicas para fins de teste, como Sauce Labs, BrowserStack, BitBar e assim por diante. Então vamos fazer isso também! Na minha opinião, o Sauce Labs é o farm de testes em nuvem mais famoso, por isso o usei para comparação.
GCP vs Sauce Labs para fins de automação:
Vamos imaginar que precisamos executar 8 testes web e 8 testes Android simultaneamente. Para isso utilizaremos GCP e rodaremos 2 máquinas virtuais com Selenoid. No primeiro levantaremos 8 containers com navegadores. No segundo existem 8 containers com emuladores. Vamos dar uma olhada nos preços:
Para executar um contêiner com o Chrome, precisamos n1-padrão-1 carro. No caso do Android será n1-padrão-4 para um emulador. Na verdade, uma maneira mais flexível e barata é definir valores específicos do usuário para CPU/Memória, mas no momento isso não é importante para comparação com o Sauce Labs.
E aqui estão as tarifas de uso do Sauce Labs:
Acredito que você já tenha notado a diferença, mas ainda vou disponibilizar uma tabela com cálculos para nossa tarefa:
Recursos necessários
Mensalmente
Horas de trabalho(8h - 8h)
Horas de trabalho+ Preemptivo
GCP para Web
n1-padrão-1 x 8 = n1-padrão-8
$194.18
23 dias * 12h * 0.38 = $ 104.88
23 dias * 12h * 0.08 = $ 22.08
Laboratórios de Molhos para Web
Testes paralelos do Virtual Cloud8
$1.559
-
-
GCP para Android
n1-padrão-4 x 8: n1-padrão-16
$776.72
23 dias * 12h * 1.52 = $ 419.52
23 dias * 12h * 0.32 = $ 88.32
Laboratórios de molho para Android
Testes paralelos do Real Device Cloud 8
$1.999
-
-
Como você pode ver, a diferença de custo é enorme, principalmente se você executar testes apenas durante um período de trabalho de doze horas. Mas você pode reduzir ainda mais os custos se usar máquinas preemptivas. O que é?
Uma VM preemptiva é uma instância que você pode criar e executar a um preço muito mais baixo do que as instâncias normais. No entanto, o Compute Engine poderá encerrar (antecipar) essas instâncias se exigir acesso a esses recursos para outras tarefas. As instâncias preemptivas são capacidade excessiva do Compute Engine, portanto, a disponibilidade delas varia de acordo com o uso.
Se seus aplicativos forem tolerantes a falhas e puderem suportar possíveis preempções de instância, as instâncias preemptivas poderão reduzir significativamente os custos do Compute Engine. Por exemplo, trabalhos de processamento em lote podem ser executados em instâncias preemptivas. Se algumas dessas instâncias terminarem durante o processamento, a tarefa ficará lenta, mas não será completamente interrompida. As instâncias preemptivas concluem suas tarefas de processamento em lote sem colocar carga de trabalho adicional nas instâncias existentes e sem exigir que você pague o preço total por instâncias normais adicionais.
E ainda não acabou! Na verdade, tenho certeza de que ninguém faz testes por 12 horas sem intervalo. E se sim, você pode iniciar e parar máquinas virtuais automaticamente quando elas não forem necessárias. O tempo real de uso pode ser reduzido para 6 horas por dia. Então o pagamento no contexto da nossa tarefa diminuirá para US$ 11 por mês para 8 navegadores. Isso não é maravilhoso? Mas com máquinas preemptivas devemos ter cuidado e estar preparados para interrupções e instabilidade, embora estas situações possam ser previstas e tratadas por software. Vale a pena!
Mas de forma alguma estou dizendo ‘nunca use farms de testes em nuvem’. Eles têm uma série de vantagens. Em primeiro lugar, esta não é apenas uma máquina virtual, mas uma solução completa de automação de testes 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, esta pode ser uma alternativa chique essencial. As plataformas de teste são especialmente úteis para automação de IOS, quando as nuvens públicas só podem oferecer sistemas Linux/Windows. Mas falaremos sobre iOS nos artigos seguintes. Recomendo sempre olhar a situação e começar pelas tarefas: em alguns casos é mais barato e mais eficiente usar nuvens públicas, e em outros as plataformas de teste definitivamente valem o dinheiro gasto.
Ilustração do estado atual da infraestrutura
Links para explorar
Ferramentas semelhantes:
6. Orquestração
Breve descrição da tecnologia
Tenho boas notícias – estamos quase no final do artigo! No momento, nossa infraestrutura de automação consiste em testes web e Android, que executamos em paralelo através do GitLab CI, usando ferramentas habilitadas para Docker: Selenium grid e Selenoid. Além disso, utilizamos máquinas virtuais criadas via GCP para hospedar containers com navegadores e emuladores. Para reduzir custos, iniciamos essas máquinas virtuais apenas sob demanda e paramos quando os testes não estão sendo realizados. Há mais alguma coisa que possa melhorar nossa infraestrutura? A resposta é sim! Conheça o Kubernetes (K8s)!
Primeiro, vamos ver como as palavras orquestração, cluster e Kubernetes estão relacionadas entre si. Em alto nível, a orquestração é o sistema que implanta e gerencia aplicativos. Para automação de testes, esses aplicativos em contêineres são Selenium grid e Selenoid. Docker e K8s se complementam. O primeiro é usado para implantação de aplicativos, o segundo para orquestração. Por sua vez, K8s é um cluster. A tarefa do cluster é usar VMs como nós, o que permite instalar diversas funcionalidades, programas e serviços dentro de um servidor (cluster). Se algum dos Nodes falhar, outros Nodes serão atendidos, o que garante o funcionamento ininterrupto da nossa aplicação. Além disso, o K8s possui importantes funcionalidades relacionadas ao escalonamento, graças às quais obtemos automaticamente a quantidade ideal de recursos com base na carga e nos limites definidos.
Na verdade, implantar manualmente o Kubernetes do zero não é uma tarefa trivial. Vou deixar um link para o famoso guia prático "Kubernetes The Hard Way" e se você estiver interessado, pode praticá-lo. Mas, felizmente, existem métodos e ferramentas alternativas. A maneira mais fácil é usar o Google Kubernetes Engine (GKE) no GCP, que permitirá obter um cluster pronto com apenas alguns cliques. Eu recomendo usar esta abordagem para começar a aprender, pois ela permitirá que você se concentre em aprender como usar os K8s para suas tarefas, em vez de aprender como os componentes internos devem ser integrados entre si.
Valor para infraestrutura de automação
Vamos dar uma olhada em alguns recursos importantes que o K8s oferece:
- implantação de aplicativos: usando um cluster de vários nós em vez de VMs;
- escalabilidade dinâmica: reduz o custo de recursos que são usados apenas sob demanda;
- autocura: recuperação automática de pods (como resultado da restauração de contêineres);
- implementação de atualizações e reversões de alterações sem tempo de inatividade: a atualização de ferramentas, navegadores e emuladores não interrompe o trabalho dos usuários atuais
Mas o K8s ainda não é uma solução mágica. Para compreender todas as vantagens e limitações no contexto das ferramentas que estamos considerando (grade Selenium, Selenoid), discutiremos brevemente a estrutura dos K8s. O cluster contém dois tipos de nós: nós mestres e nós de trabalho. Os Master Nodes são responsáveis pelas decisões de gerenciamento, implantação e agendamento. Os nós de trabalho são onde os aplicativos são iniciados. Os nós também contêm um ambiente de tempo de execução de contêiner. No nosso caso, trata-se do Docker, responsável pelas operações relacionadas a contêineres. Mas também existem soluções alternativas, por exemplo. É importante compreender que o dimensionamento ou a autocorreção não se aplicam diretamente aos contêineres. Isso é implementado adicionando/diminuindo 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 nós de trabalho, dentro dos quais existem pods, dentro dos quais os contêineres são gerados.
O recurso de escalonamento é fundamental e pode ser aplicado a nós em um pool de nós de cluster e a pods em um nó. Existem 2 tipos de dimensionamento que se aplicam a nós e pods. O primeiro tipo é horizontal - o dimensionamento ocorre aumentando o número de nós/pods. Este tipo é mais preferível. O segundo tipo é, portanto, vertical. O dimensionamento é realizado aumentando o tamanho dos nós/pods, e não seu número.
Agora vamos examinar nossas ferramentas no contexto dos termos acima.
Grade de selênio
Conforme mencionado anteriormente, a grade Selenium é uma ferramenta muito popular e não é surpresa que tenha sido conteinerizada. Portanto, não é nenhuma surpresa que a grade Selenium possa ser implantada em K8s. Um exemplo de como fazer isso pode ser encontrado no repositório oficial do K8s. Como de costume, anexo links no final da seção. Além disso, o guia prático mostra como fazer isso no Terraform. Também há instruções sobre como dimensionar o número de pods que contêm contêineres de navegador. Mas a função de escalonamento automático no contexto dos K8s ainda não é uma tarefa completamente óbvia. Quando comecei a estudar, não encontrei nenhuma orientação ou recomendação prática. Após diversos estudos e experimentos com o apoio da equipe DevOps, optamos pela abordagem de levantar contêineres com os navegadores necessários dentro de um pod, que está localizado dentro de um nó trabalhador. Este método permite-nos aplicar a estratégia de escalonamento horizontal de nós aumentando o seu número. Espero que isso mude no futuro e vejamos cada vez mais descrições de melhores abordagens e soluções prontas, especialmente após o lançamento do Selenium grid 4 com uma arquitetura interna alterada.
Selenóide:
A implantação do Selenoid nos K8s é atualmente a maior decepção. Eles não são compatíveis. Em teoria, podemos criar um contêiner Selenoid dentro de um pod, mas quando o Selenoid começar a lançar contêineres com navegadores, eles ainda estarão dentro do mesmo pod. Isso torna o escalonamento impossível e, como resultado, o trabalho do Selenoid dentro de um cluster não será diferente do trabalho dentro de uma máquina virtual. Fim da história.
Moon:
Conhecendo esse gargalo ao trabalhar com o Selenoid, os desenvolvedores lançaram uma ferramenta mais poderosa chamada Moon. Esta ferramenta foi originalmente projetada para funcionar com Kubernetes e, como resultado, o recurso de escalonamento automático pode e deve ser usado. Além disso, diria que neste momento é apenas uma ferramenta no mundo Selenium, que possui suporte nativo a cluster K8s pronto para uso (não está mais disponível, veja a próxima ferramenta ). Os principais recursos do Moon que fornecem esse suporte são:
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 o processo travar, todas as sessões em execução serão perdidas. Por outro lado, Moon não tem estado interno e pode ser replicado em data centers. As sessões do navegador permanecem ativas mesmo se uma ou mais réplicas ficarem inativas.
Então, Moon é uma ótima solução, mas há um problema: não é gratuito. O preço depende do número de sessões. Você só pode realizar de 0 a 4 sessões 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 variar de empresa para empresa, mas no nosso caso, usar Moon é inútil. Conforme descrevi acima, podemos executar VMs com Selenium Grid sob demanda ou aumentar o número de Nodes no cluster. Para 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 adicional de 500 x 5 = $ 2500 por mês, não importa quantas vezes executassemos testes. Novamente, não estou dizendo para não usar Moon. Para as suas tarefas, esta pode ser uma solução indispensável, por exemplo, se tiver muitos projetos/equipas na sua organização e precisar 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 russa)
Como eu disse, o Selenium é uma ferramenta muito popular e a área de TI está se desenvolvendo muito rapidamente. Enquanto eu trabalhava na tradução, uma nova ferramenta promissora chamada Callisto apareceu na web (olá Cypress e outros assassinos de Selenium). Ele funciona nativamente com K8s e permite executar contêineres Selenoid em pods, distribuídos entre nós. Tudo funciona imediatamente, incluindo o escalonamento automático. Fantástico, mas precisa ser testado. Já consegui implantar esta ferramenta e realizar vários experimentos. Mas ainda é cedo para tirar conclusões, depois de receber resultados à distância, talvez faça uma revisão em artigos futuros. Por enquanto deixo apenas links para pesquisas independentes.
Ilustração do estado atual da infraestrutura
Links para explorar
Ferramentas semelhantes
7. Infraestrutura como Código (IaC)
Breve descrição da tecnologia
E agora chegamos à última seção. Normalmente, esta tecnologia e tarefas relacionadas não são de responsabilidade dos engenheiros de automação. E há razões para isso. Em primeiro lugar, em muitas organizações, as questões de infraestrutura estão sob o controle do departamento DevOps e as equipes de desenvolvimento não se importam realmente com o que faz o pipeline funcionar e como tudo relacionado a ele precisa ser suportado. Em segundo lugar, sejamos honestos, a prática de Infraestrutura como Código (IaC) ainda não é adotada em muitas empresas. Mas tornou-se definitivamente uma tendência popular e é importante tentar estar envolvido nos processos, abordagens e ferramentas a ela associadas. Ou pelo menos mantenha-se atualizado.
Vamos começar com a motivação para usar essa abordagem. Já discutimos que para executar testes no GitlabCI, precisaremos no mínimo dos recursos para executar o Gitlab Runner. E para executar contêineres com navegadores/emuladores, precisamos reservar uma VM ou cluster. Além de recursos de teste, precisamos de uma quantidade significativa de capacidade para suportar ambientes de desenvolvimento, preparação e produção, o que também inclui bancos de dados, agendamentos automáticos, configurações de rede, balanceadores de carga, direitos de usuário e assim por diante. A questão principal é o esforço necessário para apoiar tudo isso. Existem várias maneiras de fazer alterações e implementar 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 seria usar chamadas de API para interagir com entidades da nuvem ou usar o utilitário de linha de comando gcloud para realizar as manipulações desejadas. Mas com um número realmente grande de entidades e elementos de infraestrutura diferentes, torna-se difícil ou mesmo impossível realizar todas as operações manualmente. Além disso, todas estas ações manuais são incontroláveis. Não podemos submetê-los para revisão antes da execução, usar um sistema de controle de versão e reverter rapidamente as alterações que levaram ao incidente. Para resolver esses problemas, os engenheiros criaram e criam scripts bash/shell automáticos, que não são muito melhores que os métodos anteriores, pois não são tão fáceis de ler, entender, manter e modificar rapidamente em um estilo processual.
Neste artigo e guia prático, utilizo 2 ferramentas relacionadas à prática de IaC. Estes são Terraform e Ansible. Algumas pessoas acreditam que não faz sentido utilizá-los ao mesmo tempo, pois suas funcionalidades são semelhantes e são intercambiáveis. Mas o fato é que inicialmente eles recebem tarefas completamente diferentes. E o fato de que essas ferramentas deveriam se complementar foi confirmado em uma apresentação conjunta de desenvolvedores representando a HashiCorp e a RedHat. A diferença conceitual é que o Terraform é uma ferramenta de provisionamento para gerenciar os próprios servidores. Já o Ansible é uma ferramenta de gerenciamento de configuração cuja tarefa é instalar, configurar e gerenciar software nesses servidores.
Outra característica distintiva importante dessas ferramentas é o estilo de codificação. Ao contrário do bash e do Ansible, o Terraform usa um estilo declarativo baseado em uma descrição do estado final desejado a ser alcançado como resultado da execução. Por exemplo, se vamos criar 10 VMs e aplicar as alterações através do Terraform, obteremos 10 VMs. Se executarmos 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ê solicitar a criação de 10 VMs, na primeira inicialização obteremos 10 VMs, semelhante ao Terraform. Mas depois de reiniciar já teremos 20 VMs. Esta é a diferença importante. No estilo processual, não armazenamos o estado atual e simplesmente descrevemos uma sequência de passos que devem ser executados. Claro que podemos lidar com diversas situações, adicionar diversas verificações da existência de recursos e do estado atual, mas não adianta perder tempo e nos esforçarmos para controlar essa lógica. Além disso, aumenta o risco de cometer erros.
Resumindo tudo o que foi dito acima, podemos concluir que o Terraform e a notação declarativa são uma ferramenta mais adequada para provisionamento de servidores. Mas é melhor delegar o trabalho de gerenciamento de configuração ao Ansible. Com isso resolvido, vamos examinar os casos de uso no contexto da automação.
Valor para infraestrutura de automação
A única coisa importante a entender aqui é que a infraestrutura de automação de testes deve ser considerada como parte de toda a infraestrutura da empresa. Isto 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 DevOps é mais experiente nessas questões, eles têm uma visão geral 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 mudanças necessárias e oportunidades de melhoria. A melhor opção é trabalhar em conjunto, trocar conhecimentos e ideias para alcançar o resultado esperado.
Aqui estão alguns exemplos de uso do Terraform e Ansible no contexto de automação de testes e das ferramentas que discutimos anteriormente:
1. Descreva as características e parâmetros necessários de VMs e clusters usando Terraform.
2. Usando Ansible, instale as ferramentas necessárias para teste: docker, Selenoid, Selenium Grid e baixe as versões necessárias de navegadores/emuladores.
3. Usando o Terraform, descreva as características da VM na qual o GitLab Runner será lançado.
4. Instale o GitLab Runner e as ferramentas necessárias usando Ansible, defina definições e configurações.
Ilustração do estado atual da infraestrutura
Links para explorar:
Ferramentas semelhantes
Vamos resumir!
Passo
Equipar
Ferramentas
Valor para infraestrutura de automação
1
Corrida local
Node.js, Selênio, Appium
- As ferramentas mais populares para web e dispositivos móveis
- Suporta muitas linguagens e plataformas (incluindo Node.js)
2
Sistemas de controle de versão
Git
- Benefícios semelhantes com código de desenvolvimento
3
Conteinerização
Docker, grade Selenium, Selenoid (Web, Android)
- Executando testes em paralelo
- Ambientes isolados
- Atualizações de versão simples e flexíveis
- Parando dinamicamente recursos não utilizados
- Fácil de configurar
4
CI/CD
CI do Gitlab
- Testa parte do pipeline
- Feedback rápido
- Visibilidade para toda a empresa/equipe
5
Plataformas de nuvem
Google Cloud Platform
- Recursos sob demanda (pagamos apenas quando necessário)
- 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 de pods:
- Dimensionamento/escalonamento automático
- Autocura
- Atualizações e reversões sem interrupção
7
Infraestrutura como 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
etapa 1: Local
etapa 2: VCS
etapa 3: Conteinerização
etapa 4: CI/CD
etapa 5: plataformas em nuvem
etapa 6: Orquestração
etapa 7: IaC
Qual é o próximo?
Então, este é o fim do artigo. Mas para concluir, gostaria de estabelecer alguns acordos com vocês.
Do seu lado
Como disse no início, gostaria que o artigo fosse de utilidade prática e ajudasse você a aplicar os conhecimentos adquiridos no trabalho real. eu adiciono novamente.
Mas mesmo depois disso, não pare, pratique, estude links e livros relevantes, descubra como funciona na sua empresa, encontre lugares que podem ser melhorados e participe. Boa sorte!
Do meu lado
Pelo título você pode ver que esta foi apenas a primeira parte. Apesar de ter sido bastante extenso, tópicos importantes ainda não são abordados aqui. Na segunda parte, pretendo examinar a infraestrutura de automação no contexto do IOS. Devido às restrições da Apple em executar simuladores iOS apenas em sistemas macOS, nossa gama de soluções é reduzida. Por exemplo, não podemos usar o 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 atualizado com soluções avançadas e ferramentas modernas!
Além disso, não mencionei tópicos muito extensos relacionados ao monitoramento. Na Parte 3, examinarei as ferramentas de monitoramento de infraestrutura mais populares e quais dados e métricas considerar.
E finalmente. No futuro, pretendo lançar um curso em vídeo sobre como construir infraestrutura de teste e ferramentas populares. Atualmente, existem alguns cursos e palestras sobre DevOps na Internet, mas todos os materiais são apresentados no contexto de desenvolvimento e não de automação de testes. Sobre esta questão, eu realmente preciso de feedback sobre se tal curso será interessante e valioso para a comunidade de testadores e engenheiros de automação. Agradeço antecipadamente!
Fonte: habr.com