Parte 1: Web/Android
Nota: este artigo é unha tradución ao ruso do artigo orixinal Non obstante, todas as ilustracións, ligazóns, citas e termos consérvanse na lingua orixinal para evitar a distorsión do significado cando se traducen ao ruso. Deséxoche feliz estudando!
Actualmente, a especialidade DevOps é unha das máis demandadas na industria das TI. Se abres sitios populares de busca de emprego e filtras por salario, verás que os traballos relacionados con DevOps están na parte superior da lista. Non obstante, é importante entender que isto refírese principalmente a un posto de 'Senior', o que implica que o candidato posúe un alto nivel de habilidades, coñecementos de tecnoloxía e ferramentas. Isto tamén vén cun alto grao de responsabilidade asociado ao funcionamento ininterrompido da produción. Non obstante, comezamos a esquecer o que é DevOps. Inicialmente, non era ningunha persoa ou departamento específico. Se buscamos definicións deste termo, atoparemos moitos substantivos fermosos e correctos, como metodoloxía, prácticas, filosofía cultural, grupo de conceptos, etc.
A miña especialización é enxeñeiro de automatización de probas (enxeñeiro de automatización de control de calidade), pero creo que non debería asociarse só coa escritura de probas automáticas ou o desenvolvemento de arquitectura de marco de proba. En 2020 tamén é fundamental o coñecemento da infraestrutura de automatización. Isto permítelle organizar vostede mesmo o proceso de automatización, desde a realización de probas ata ofrecer resultados a todas as partes interesadas de acordo cos seus obxectivos. Como resultado, as habilidades de DevOps son imprescindibles para facer o traballo. E todo isto é bo, pero, por desgraza, hai un problema (spoiler: este artigo intenta simplificar este problema). A cuestión é que DevOps é difícil. E isto é obvio, porque as empresas non pagarán moito por algo que é fácil de facer... No mundo DevOps, hai un gran número de ferramentas, termos e prácticas que hai que dominar. Isto é especialmente difícil ao comezo dunha carreira e depende da experiencia técnica acumulada.
Fonte:
Aquí probablemente remataremos coa parte introdutoria e centraremos o propósito deste artigo.
De que trata este artigo?
Neste artigo, vou compartir a miña experiencia na construción dunha infraestrutura de automatización de probas. Hai moitas fontes de información en Internet sobre varias ferramentas e como usalas, pero gustaríame miralas exclusivamente no contexto da automatización. Creo que moitos enxeñeiros de automatización están familiarizados coa situación na que ninguén, excepto ti, realiza as probas desenvolvidas ou se preocupa por mantelas. Como resultado, as probas quedan desactualizadas e tes que dedicar tempo a actualizalas. Unha vez máis, ao comezo dunha carreira, esta pode ser unha tarefa bastante difícil: decidir sabiamente que ferramentas deben axudar a eliminar un determinado problema, como seleccionalas, configuralas e mantelas. Algúns probadores recorren a DevOps (humanos) para pedir axuda e, sexamos honestos, este enfoque funciona. En moitos casos esta pode ser a única opción xa que non temos visibilidade de todas as dependencias. Pero como sabemos, os DevOps son rapaces moi ocupados, porque teñen que pensar en toda a infraestrutura, despregamento, seguimento, microservizos e outras tarefas similares de toda a empresa dependendo da organización/equipo. Como é habitual, a automatización non é unha prioridade. Neste caso, debemos tentar facer todo o posible pola nosa parte de principio a fin. Isto reducirá as dependencias, acelerará o fluxo de traballo, mellorará as nosas habilidades e permitiranos ver unha imaxe máis ampla do que está a suceder.
O artigo presenta as ferramentas máis populares e populares e mostra como usalas para construír unha infraestrutura de automatización paso a paso. Cada grupo está representado por ferramentas que foron probadas a través da experiencia persoal. Pero iso non significa que teñas que usar o mesmo. As ferramentas en si non son importantes, aparecen e quedan obsoletas. A nosa tarefa de enxeñaría é comprender os principios básicos: por que necesitamos este grupo de ferramentas e que problemas de traballo podemos resolver coa súa axuda. É por iso que ao final de cada sección deixo ligazóns a ferramentas similares que se poden utilizar na súa organización.
O que non está neste artigo
Repito unha vez máis que o artigo non trata de ferramentas específicas, polo que non haberá insercións de código da documentación e descricións de comandos específicos. Pero ao final de cada sección deixo enlaces para o seu estudo detallado.
Isto faise porque:
- este material é moi doado de atopar en diversas fontes (documentación, libros, videocursos);
- se empezamos a afondar, teremos que escribir 10, 20, 30 partes deste artigo (mentres os plans son 2-3);
- Non quero perder o teu tempo xa que podes querer usar outras ferramentas para acadar os mesmos obxectivos.
Práctica
Gustaríame moito que este material fose útil para todos os lectores, e non só lido e esquecido. En calquera estudo, a práctica é un compoñente moi importante. Para iso teño preparado. Tamén hai deberes agardando por ti para asegurarte de non copiar sen pensar as liñas dos comandos que estás executando.
Planificar
Paso
tecnoloxía
ferramentas
1
Execución local (prepare probas de demostración web/android e execute-lo localmente)
Node.js, Selenium, Appium
2
Sistemas de control de versións
ir
3
Containerización
Docker, Selenium grid, Selenoid (Web, Android)
4
CI/CD
Gitlab CI
5
Plataformas na nube
Google Cloud Platform
6
Orquestración
Kubernetes
7
Infraestrutura como código (IaC)
Terraform, Ansible
Estrutura de cada sección
Para manter a narrativa clara, cada sección descríbese segundo o seguinte esquema:
- Breve descrición da tecnoloxía,
- valor para a infraestrutura de automatización,
- ilustración do estado actual da infraestrutura,
- enlaces para estudar,
- ferramentas similares.
1. Realiza probas localmente
Breve descrición da tecnoloxía
Este é só un paso preparatorio para executar as probas de demostración localmente e verificar que as superan. Na parte práctica utilízase Node.js, pero a linguaxe de programación e a plataforma tampouco son importantes e podes utilizar os que se usan na túa empresa.
Non obstante, como ferramentas de automatización, recomendo utilizar Selenium WebDriver para plataformas web e Appium para a plataforma Android, respectivamente, xa que nos próximos pasos usaremos imaxes de Docker adaptadas para traballar especificamente con estas ferramentas. Ademais, en referencia ás esixencias do traballo, estas ferramentas son as máis demandadas no mercado.
Como podes ter notado, só consideramos probas web e Android. Desafortunadamente, iOS é unha historia completamente diferente (grazas Apple). Planeo mostrar solucións e prácticas relacionadas con IOS nas próximas partes.
Valor para a infraestrutura de automatización
Desde a perspectiva das infraestruturas, executar localmente non aporta ningún valor. Só verifica que as probas se executen na máquina local en navegadores e simuladores locais. Pero en calquera caso, este é un punto de partida necesario.
Ilustración do estado actual das infraestruturas
Ligazóns para explorar
Ferramentas semellantes
- calquera linguaxe de programación que lle guste xunto coas probas de Selenium/Appium;
- calquera proba;
- calquera corredor de proba.
2. Sistemas de control de versións (Git)
Breve descrición da tecnoloxía
Non será unha gran revelación para ninguén se digo que o control de versións é unha parte extremadamente importante do desenvolvemento, tanto en equipo como individualmente. Baseándose en varias fontes, é seguro dicir que Git é o representante máis popular. Un sistema de control de versións ofrece moitos beneficios, como compartir código, almacenar versións, restaurar a ramas anteriores, supervisar o historial de proxectos e facer copias de seguridade. Non comentaremos cada punto en detalle, xa que estou seguro de que está moi familiarizado con el e utilizalo no seu traballo diario. Pero se de súpeto non é así, recomendo que deixes de ler este artigo e enche este oco canto antes.
Valor para a infraestrutura de automatización
E aquí podes facer unha pregunta razoable: "Por que nos fala de Git? Todo o mundo sabe isto e utilízao tanto para o código de desenvolvemento como para o código de proba automática. Terás toda a razón, pero neste artigo estamos a falar de infraestruturas e esta sección actúa como unha vista previa da sección 7: "Infraestrutura como código (IaC)". Para nós, isto significa que toda a infraestrutura, incluídas as probas, descríbese en forma de código, polo que tamén podemos aplicarlle sistemas de versionado e obter beneficios similares aos do código de desenvolvemento e automatización.
Veremos IaC con máis detalle no paso 7, pero aínda agora podes comezar a usar Git localmente creando un repositorio local. O panorama ampliarase cando engadimos un repositorio remoto á infraestrutura.
Ilustración do estado actual das infraestruturas
Ligazóns para explorar
Ferramentas semellantes
3. Containerización (Docker)
Breve descrición da tecnoloxía
Para demostrar como a contenerización cambiou as regras do xogo, retrocedamos no tempo unhas décadas. Daquela, a xente compraba e usaba máquinas servidores para executar aplicacións. Pero na maioría dos casos, os recursos de inicio necesarios non se coñecían de antemán. Como resultado, as empresas gastaron diñeiro na compra de servidores caros e potentes, pero parte desta capacidade non se utilizou completamente.
A seguinte etapa de evolución foron as máquinas virtuais (VM), que resolveron o problema de malgastar diñeiro en recursos non utilizados. Esta tecnoloxía permitiu executar aplicacións independentemente unhas das outras dentro do mesmo servidor, asignando espazo completamente illado. Pero, por desgraza, calquera tecnoloxía ten os seus inconvenientes. A execución dunha máquina virtual require un sistema operativo completo, que consome CPU, RAM, almacenamento e, dependendo do SO, hai que ter en conta os custos de licenza. Estes factores afectan a velocidade de carga e dificultan a portabilidade.
E agora chegamos á contenerización. Unha vez máis, esta tecnoloxía resolve o problema anterior, xa que os contedores non usan un SO completo, o que libera unha gran cantidade de recursos e proporciona unha solución rápida e flexible para a portabilidade.
Por suposto, a tecnoloxía de contenerización non é nada novo e foi introducida por primeira vez a finais dos anos 70. Naqueles tempos, realizáronse moitas investigacións, desenvolvementos e intentos. Pero foi Docker quen adaptou esta tecnoloxía e fíxoa facilmente accesible para as masas. Hoxe en día, cando falamos de contedores, na maioría dos casos referímonos a Docker. Cando falamos de contedores Docker, referímonos aos contedores Linux. Podemos utilizar os sistemas Windows e macOS para executar contedores, pero é importante entender que neste caso aparece unha capa adicional. Por exemplo, Docker en Mac executa silenciosamente contedores dentro dunha máquina virtual Linux lixeira. Volveremos sobre este tema cando discutamos sobre a execución de emuladores de Android dentro de contedores, polo que aquí hai un matiz moi importante que debe ser discutido con máis detalle.
Valor para a infraestrutura de automatización
Descubrimos que a contenerización e Docker son xeniais. Vexamos isto no contexto da automatización, porque cada ferramenta ou tecnoloxía precisa resolver un problema. Describamos os problemas obvios da automatización das probas no contexto das probas da IU:
- un gran número de dependencias á hora de instalar Selenium e especialmente Appium;
- problemas de compatibilidade entre versións de navegadores, simuladores e controladores;
- falta de espazo illado para navegadores/simuladores, o que é especialmente crítico para a execución en paralelo;
- difícil de xestionar e manter se precisa executar 10, 50, 100 ou mesmo 1000 navegadores ao mesmo tempo.
Pero dado que Selenium é a ferramenta de automatización máis popular e Docker é a ferramenta de contenerización máis popular, non debería sorprender que alguén intente combinalos para crear unha poderosa ferramenta para resolver os problemas mencionados anteriormente. Consideremos tales solucións con máis detalle.
Reixa de selenio no docker
Esta ferramenta é a máis popular no mundo de Selenium para executar varios navegadores en varias máquinas e xestionalos desde un hub central. Para comezar, cómpre rexistrar polo menos 2 partes: Hub e Node(s). Hub é un nodo central que recibe todas as solicitudes das probas e distribúeas aos nodos apropiados. Para cada Nodo podemos configurar unha configuración específica, por exemplo, especificando o navegador desexado e a súa versión. Non obstante, aínda temos que coidar nós mesmos os controladores de navegador compatibles e instalalos nos Nodos desexados. Por este motivo, Selenium grid non se usa na súa forma pura, excepto cando necesitamos traballar con navegadores que non se poden instalar no sistema operativo Linux. Para todos os demais casos, unha solución significativamente flexible e correcta sería usar imaxes de Docker para executar Selenium grid Hub and Nodes. Este enfoque simplifica moito a xestión dos nodos, xa que podemos seleccionar a imaxe que necesitamos con versións compatibles de navegadores e controladores xa instalados.
A pesar das críticas negativas sobre a estabilidade, especialmente cando se executan un gran número de Nodos en paralelo, Selenium grid segue sendo a ferramenta máis popular para realizar probas de Selenium en paralelo. É importante ter en conta que varias melloras e modificacións desta ferramenta aparecen constantemente en código aberto, que combaten varios pescozos de botella.
Selenoid para web
Esta ferramenta é un gran avance no mundo de Selenium xa que funciona desde a caixa e facilitou moito a vida de moitos enxeñeiros de automatización. En primeiro lugar, esta non é outra modificación da reixa de selenio. Pola contra, os desenvolvedores crearon unha versión completamente nova de Selenium Hub en Golang, que, combinada con imaxes lixeiras de Docker para varios navegadores, deu impulso ao desenvolvemento da automatización de probas. Ademais, no caso de Selenium Grid, debemos determinar previamente todos os navegadores necesarios e as súas versións, o que non supón ningún problema cando se traballa cun só navegador. Pero cando se trata de varios navegadores compatibles, Selenoid é a solución número un grazas á súa función de "navegador baixo demanda". O único que se nos esixe é descargar previamente con navegadores as imaxes necesarias e actualizar o ficheiro de configuración co que interactúa Selenoid. Despois de que Selenoid reciba unha solicitude das probas, lanzará automaticamente o contedor desexado co navegador desexado. Cando finalice a proba, Selenoid retirará o contedor, liberando así recursos para futuras solicitudes. Este enfoque elimina por completo o coñecido problema da "degradación dos nodos" que adoitamos atopar na rede Selenium.
Pero, por desgraza, Selenoid aínda non é unha bala de prata. Temos a función "navegador baixo demanda", pero a función "recursos baixo demanda" aínda non está dispoñible. Para usar Selenoid, debemos implantalo en hardware físico ou nunha máquina virtual, o que significa que debemos saber de antemán cantos recursos hai que asignar. Supoño que isto non é un problema para proxectos pequenos que executan 10, 20 ou mesmo 30 navegadores en paralelo. Pero e se necesitamos 100, 500, 1000 ou máis? Non ten sentido manter e pagar tantos recursos todo o tempo. Nas seccións 5 e 6 deste artigo, comentaremos solucións que che permiten escalar, reducindo así significativamente os custos da empresa.
Selenoid para Android
Despois do éxito de Selenoid como ferramenta de automatización web, a xente quería algo similar para Android. E pasou: Selenoid foi lanzado con soporte para Android. Desde o punto de vista do usuario de alto nivel, o principio de funcionamento é similar á automatización web. A única diferenza é que en lugar de contedores de navegador, Selenoid executa contedores de emuladores de Android. Na miña opinión, esta é actualmente a ferramenta gratuíta máis poderosa para realizar probas de Android en paralelo.
Realmente non me gustaría falar dos aspectos negativos desta ferramenta, xa que me gusta moito. Pero aínda así, hai as mesmas desvantaxes que se aplican á automatización web e están asociadas á escala. Ademais disto, cómpre falar dunha limitación máis que pode sorprender se configuramos a ferramenta por primeira vez. Para executar imaxes de Android, necesitamos unha máquina física ou máquina virtual con soporte de virtualización anidada. Na guía de instrucións, demostro como activalo nunha máquina virtual Linux. Non obstante, se es un usuario de macOS e queres implementar Selenoid localmente, non será posible realizar probas de Android. Pero sempre pode executar unha máquina virtual Linux localmente coa "virtualización anidada" configurada e implementar Selenoid dentro.
Ilustración do estado actual das infraestruturas
No contexto deste artigo, engadiremos 2 ferramentas para ilustrar a infraestrutura. Estes son Selenium grid para probas web e Selenoid para probas de Android. No tutorial de GitHub, tamén che mostrarei como usar Selenoid para realizar probas web.
Ligazóns para explorar
Ferramentas semellantes
- Hai outras ferramentas de contenerización, pero Docker é a máis popular. Se queres probar outra cousa, ten en conta que as ferramentas que cubrimos para realizar probas de Selenium en paralelo non funcionarán de forma inmediata.
- Como xa se dixo, hai moitas modificacións na reixa de selenio, por exemplo,.
4.CI/CD
Breve descrición da tecnoloxía
A práctica da integración continua é bastante popular no desenvolvemento e está á par dos sistemas de control de versións. A pesar diso, sinto que hai confusión na terminoloxía. Neste parágrafo gustaríame describir 3 modificacións desta tecnoloxía dende o meu punto de vista. En internet atoparás moitos artigos con diferentes interpretacións, e é absolutamente normal que a túa opinión difire. O máis importante é que esteas na mesma páxina cos teus compañeiros.
Entón, hai 3 termos: CI - Integración continua, CD - Entrega continua e de novo CD - Implementación continua. (A continuación usarei estes termos en inglés). Cada modificación engade varios pasos adicionais ao teu pipeline de desenvolvemento. Pero a palabra continuo (continuo) é o máis importante. Neste contexto, entendemos algo que sucede de principio a fin, sen interrupción nin intervención manual. Vexamos CI & CD e CD neste contexto.
- Integración Continua este é o paso inicial da evolución. Despois de enviar un novo código ao servidor, esperamos recibir comentarios rápidos de que os nosos cambios están correctos. Normalmente, CI inclúe a execución de ferramentas de análise de código estático e probas de API unitarias/internas. Isto permítenos obter información sobre o noso código nuns segundos/minutos.
- Entrega continua é un paso máis avanzado no que realizamos probas de integración/UI. Non obstante, nesta fase non obtemos resultados tan rápido como con CI. En primeiro lugar, este tipo de probas tardan máis en completarse. En segundo lugar, antes do lanzamento, debemos implementar os nosos cambios no ambiente de proba/procedimento. Ademais, se estamos a falar de desenvolvemento móbil, aparece un paso adicional para crear unha compilación da nosa aplicación.
- Despregamento continuo asume que liberamos automaticamente os nosos cambios na produción se todas as probas de aceptación pasaron nas etapas anteriores. Ademais disto, despois da fase de lanzamento, pode configurar varias etapas, como realizar probas de fume na produción e recoller métricas de interese. A implantación continua só é posible cunha boa cobertura mediante probas automatizadas. Se é necesaria algunha intervención manual, incluídas as probas, entón xa non o é Continuo (continuo). Entón podemos dicir que o noso gasoduto só cumpre coa práctica de Entrega Continua.
Valor para a infraestrutura de automatización
Nesta sección, debería aclarar que cando falamos de probas de IU de extremo a extremo, significa que debemos implementar os nosos cambios e servizos asociados para probar ambientes. Integración continua: o proceso non é aplicable a esta tarefa e debemos encargarnos de implementar polo menos prácticas de Entrega Continua. A implementación continua tamén ten sentido no contexto das probas de IU se as imos executar en produción.
E antes de mirar a ilustración do cambio de arquitectura, quero dicir algunhas palabras sobre GitLab CI. A diferenza doutras ferramentas CI/CD, GitLab ofrece un repositorio remoto e moitas outras funcións adicionais. Así, GitLab é máis que CI. Inclúe xestión de código fonte, xestión áxil, canalizacións de CI/CD, ferramentas de rexistro e recollida de métricas sen prexuízo. A arquitectura de GitLab está formada por Gitlab CI/CD e GitLab Runner. Aquí tes unha breve descrición do sitio web oficial:
Gitlab CI/CD é unha aplicación web cunha API que almacena o seu estado nunha base de datos, xestiona proxectos/construcións e proporciona unha interface de usuario. GitLab Runner é unha aplicación que procesa compilacións. Pódese implementar por separado e funciona con GitLab CI/CD a través dunha API. Para as probas en execución, necesitas a instancia de Gitlab e Runner.
Ilustración do estado actual das infraestruturas
Ligazóns para explorar
Ferramentas semellantes
- E moitos outros
5. Plataformas na nube
Breve descrición da tecnoloxía
Neste apartado falaremos dunha tendencia popular chamada 'nubes públicas'. A pesar dos enormes beneficios que proporcionan as tecnoloxías de virtualización e containerización descritas anteriormente, aínda necesitamos recursos informáticos. As empresas compran servidores caros ou alugan centros de datos, pero neste caso é necesario facer cálculos (ás veces pouco realistas) de cantos recursos necesitaremos, se os imos empregar as 24 horas do día, os 7 días da semana e para que fins. Por exemplo, a produción require un servidor que funcione XNUMX horas ao día, XNUMX días a semana, pero necesitamos recursos similares para probar fóra do horario laboral? Tamén depende do tipo de proba que se realice. Un exemplo serían as probas de carga/esforzo que pensamos realizar durante as horas non laborables para obter resultados ao día seguinte. Pero definitivamente non é necesaria a dispoñibilidade do servidor XNUMX/XNUMX para probas automatizadas de extremo a extremo e, especialmente, para ambientes de probas manuais. Para tales situacións, sería bo obter tantos recursos como sexa necesario baixo demanda, utilizalos e deixar de pagar cando xa non sexan necesarios. Ademais, sería xenial recibilos ao instante facendo uns cantos clics do rato ou executando un par de scripts. Para iso se utilizan as nubes públicas. Vexamos a definición:
“A nube pública defínese como servizos informáticos ofrecidos por provedores de terceiros a través da Internet pública, que os pon a disposición de quen queira utilizalos ou compralos. Poden ser gratuítos ou venderse baixo demanda, o que permite aos clientes pagar só por uso dos ciclos da CPU, o almacenamento ou o ancho de banda que consumen".
Hai unha opinión de que as nubes públicas son caras. Pero a súa idea fundamental é reducir os custos da empresa. Como se mencionou anteriormente, as nubes públicas permítenche obter recursos baixo demanda e pagar só polo tempo que os usas. Ademais, ás veces esquecemos que os empregados reciben salarios, e os especialistas tamén son un recurso caro. Hai que ter en conta que as nubes públicas facilitan moito o soporte das infraestruturas, o que permite aos enxeñeiros centrarse en tarefas máis importantes.
Valor para a infraestrutura de automatización
Que recursos específicos necesitamos para probas de IU de extremo a extremo? Basicamente trátase de máquinas virtuais ou clústeres (de Kubernetes falaremos na seguinte sección) para executar navegadores e emuladores. Cantos máis navegadores e emuladores queremos executar simultaneamente, máis CPU e memoria necesitaremos e máis diñeiro teremos que pagar por iso. Así, as nubes públicas no contexto da automatización das probas permítennos executar un gran número (100, 200, 1000...) de navegadores/emuladores baixo demanda, obter resultados das probas o máis rápido posible e deixar de pagar por un uso tan inmenso de recursos. poder.
Os provedores de nube máis populares son Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP). A guía de instrucións ofrece exemplos de como usar GCP, pero en xeral non importa o que uses para tarefas de automatización. Todos proporcionan aproximadamente a mesma funcionalidade. Normalmente, para seleccionar un provedor, a xestión céntrase en toda a infraestrutura e os requisitos comerciais da empresa, o que está fóra do alcance deste artigo. Para os enxeñeiros de automatización, será máis interesante comparar o uso de provedores de nube co uso de plataformas en nube especificamente para fins de proba, como Sauce Labs, BrowserStack, BitBar, etc. Entón, imos facelo tamén! Na miña opinión, Sauce Labs é a granxa de probas na nube máis famosa, polo que a usei para comparar.
GCP vs Sauce Labs para fins de automatización:
Imaxinemos que necesitamos executar 8 probas web e 8 probas de Android simultaneamente. Para iso usaremos GCP e executaremos 2 máquinas virtuais con Selenoid. No primeiro levantaremos 8 contedores con navegadores. No segundo hai 8 contedores con emuladores. Vexamos os prezos:
Para executar un contedor con Chrome, necesitamos n1-estándar-1 coche. No caso de Android será n1-estándar-4 para un emulador. De feito, unha forma máis flexible e barata é establecer valores de usuario específicos para CPU/Memoria, pero polo momento isto non é importante para comparar con Sauce Labs.
E aquí están as tarifas para usar Sauce Labs:
Creo que xa notaches a diferenza, pero seguirei fornecendo unha táboa cos cálculos para a nosa tarefa:
Recursos necesarios
Mensuais
horas de traballo(8 am - 8 pm)
horas de traballo+ Preventivo
GCP para a web
n1-estándar-1 x 8 = n1-estándar-8
$194.18
23 días * 12 h * 0.38 = 104.88 $
23 días * 12 h * 0.08 = 22.08 $
Sauce Labs para Web
Virtual Cloud8 probas paralelas
$1.559
-
-
GCP para Android
n1-estándar-4 x 8: n1-estándar-16
$776.72
23 días * 12 h * 1.52 = 419.52 $
23 días * 12 h * 0.32 = 88.32 $
Sauce Labs para Android
Real Device Cloud 8 probas paralelas
$1.999
-
-
Como podes ver, a diferenza de custo é enorme, especialmente se realizas probas só durante un período de traballo de doce horas. Pero podes reducir os custos aínda máis se usas máquinas preemptibles. Que é?
Unha máquina virtual preventiva é unha instancia que podes crear e executar a un prezo moito menor que as instancias normais. Non obstante, Compute Engine pode cancelar (previa) estas instancias se require acceso a eses recursos para outras tarefas. As instancias preventivas son o exceso de capacidade de Compute Engine, polo que a súa dispoñibilidade varía segundo o uso.
Se as túas aplicacións son tolerantes a erros e poden soportar posibles preferencias de instancias, as instancias que se poden evitar poden reducir significativamente os custos de Compute Engine. Por exemplo, os traballos de procesamento por lotes pódense executar en instancias que se poden evitar. Se algunhas desas instancias finalizan durante o procesamento, o traballo diminúe pero non se detén por completo. As instancias preventivas completan as súas tarefas de procesamento por lotes sen poñer carga de traballo adicional nas súas instancias existentes e sen esixirlle que pague o prezo total por instancias normais adicionais.
E aínda non rematou! En realidade, estou seguro de que ninguén realiza probas durante 12 horas sen descanso. E se é así, pode iniciar e deter automaticamente as máquinas virtuais cando non sexan necesarias. O tempo de uso real pódese reducir a 6 horas ao día. Entón, o pago no contexto da nosa tarefa diminuirá a 11 dólares ao mes para 8 navegadores. Non é marabilloso? Pero coas máquinas preventivas debemos ter coidado e estar preparados para as interrupcións e a inestabilidade, aínda que estas situacións pódense prever e xestionar en software. Paga a pena!
Pero de ningún xeito estou a dicir "nunca use granxas de probas na nube". Teñen unha serie de vantaxes. En primeiro lugar, non se trata só dunha máquina virtual, senón dunha solución de automatización de probas completa cun conxunto de funcionalidades listas para a súa entrega: acceso remoto, rexistros, capturas de pantalla, gravación de vídeo, varios navegadores e dispositivos móbiles físicos. En moitas situacións, esta pode ser unha alternativa elegante e esencial. As plataformas de proba son especialmente útiles para a automatización de IOS, cando as nubes públicas só poden ofrecer sistemas Linux/Windows. Pero falaremos de iOS nos seguintes artigos. Recomendo mirar sempre a situación e partir das tarefas: nalgúns casos é máis barato e eficiente utilizar as nubes públicas, e noutros as plataformas de probas valen sen dúbida o diñeiro gastado.
Ilustración do estado actual das infraestruturas
Ligazóns para explorar
Ferramentas semellantes:
6. Orquestración
Breve descrición da tecnoloxía
Teño unha boa noticia: estamos case ao final do artigo! Polo momento, a nosa infraestrutura de automatización consta de probas web e Android, que realizamos a través de GitLab CI en paralelo, utilizando ferramentas habilitadas para Docker: Selenium grid e Selenoid. Ademais, utilizamos máquinas virtuais creadas mediante GCP para aloxar contedores con navegadores e emuladores. Para reducir custos, iniciamos estas máquinas virtuais só baixo demanda e detémolas cando non se estean a realizar as probas. Hai algo máis que poida mellorar a nosa infraestrutura? A resposta é si! Coñece Kubernetes (K8s)!
En primeiro lugar, vexamos como se relacionan as palabras orquestración, clúster e Kubernetes. A un alto nivel, a orquestración é o sistema que desprega e xestiona as aplicacións. Para a automatización das probas, tales aplicacións en contedores son Selenium grid e Selenoid. Docker e K8 se complementan. O primeiro úsase para a implantación de aplicacións, o segundo para a orquestración. Á súa vez, K8s é un clúster. A tarefa do clúster é utilizar máquinas virtuales como Nodos, o que permite instalar varias funcionalidades, programas e servizos nun servidor (clúster). Se algún dos nodos falla, outros nodos activaranse, o que garante o funcionamento ininterrompido da nosa aplicación. Ademais disto, o K8s ten unha importante funcionalidade relacionada co escalado, grazas á cal obtemos automaticamente a cantidade óptima de recursos en función da carga e os límites establecidos.
En realidade, implementar manualmente Kubernetes desde cero non é unha tarefa trivial. Deixovos unha ligazón á famosa guía "Kubernetes The Hard Way" e se che interesa, podes practicala. Pero, afortunadamente, hai métodos e ferramentas alternativas. O xeito máis sinxelo é usar Google Kubernetes Engine (GKE) en GCP, o que che permitirá obter un clúster preparado en poucos clics. Recomendo usar este enfoque para comezar a aprender, xa que che permitirá centrarte en aprender a usar os K8 para as túas tarefas en lugar de aprender como se deben integrar os compoñentes internos.
Valor para a infraestrutura de automatización
Vexamos algunhas características importantes que ofrece o K8s:
- implantación de aplicacións: usando un clúster de varios nodos en lugar de máquinas virtuales;
- escalado dinámico: reduce o custo dos recursos que se usan só baixo demanda;
- autocuración: recuperación automática das vainas (como resultado da cal tamén se restauran os recipientes);
- lanzamento de actualizacións e retrocesos de cambios sen tempo de inactividade: a actualización de ferramentas, navegadores e emuladores non interrompe o traballo dos usuarios actuais
Pero o K8 aínda non é unha bala de prata. Para comprender todas as vantaxes e limitacións no contexto das ferramentas que estamos considerando (reixa de selenio, selenoide), comentaremos brevemente a estrutura dos K8. O clúster contén dous tipos de nodos: nodos mestres e nodos traballadores. Os nodos mestres son os responsables das decisións de xestión, implantación e programación. Os nodos de traballo son onde se lanzan as aplicacións. Os nós tamén conteñen un ambiente de execución de contedores. No noso caso, trátase de Docker, que é responsable das operacións relacionadas cos contedores. Pero tamén hai solucións alternativas, por exemplo. É importante entender que a escala ou a autocuración non se aplica directamente aos recipientes. Isto realízase engadindo/diminuíndo o número de vainas, que á súa vez conteñen recipientes (normalmente un recipiente por vaina, pero dependendo da tarefa pode haber máis). A xerarquía de alto nivel está formada por nodos de traballo, dentro dos cales hai vainas, dentro das cales se levantan contedores.
A función de escalado é fundamental e pódese aplicar a ambos os nós dentro dun grupo de nodos de clúster e aos pods dentro dun nodo. Hai dous tipos de escala que se aplican tanto aos nodos como aos pods. O primeiro tipo é horizontal - a escala prodúcese aumentando o número de nodos/pods. Este tipo é máis preferible. O segundo tipo é, en consecuencia, vertical. A escala realízase aumentando o tamaño dos nodos/pods, e non o seu número.
Agora vexamos as nosas ferramentas no contexto dos termos anteriores.
Reixa de selenio
Como se mencionou anteriormente, a reixa de selenio é unha ferramenta moi popular, e non é de estrañar que teña sido contenedora. Polo tanto, non é de estrañar que a reixa de selenio se poida despregar en K8. Un exemplo de como facelo pódese atopar no repositorio oficial de K8s. Como de costume, adxunto ligazóns ao final da sección. Ademais, a guía de instrucións mostra como facelo en Terraform. Tamén hai instrucións sobre como escalar o número de pods que conteñen contedores do navegador. Pero a función de escalado automático no contexto de K8s aínda non é unha tarefa completamente obvia. Cando comecei a estudar, non atopei ningunha orientación ou recomendación práctica. Despois de varios estudos e experimentos co apoio do equipo de DevOps, escollemos o enfoque de crear contedores cos navegadores necesarios dentro dun pod, que está situado dentro dun nodo de traballo. Este método permítenos aplicar a estratexia de escalado horizontal dos nodos aumentando o seu número. Espero que isto cambie no futuro e vexamos cada vez máis descricións de mellores enfoques e solucións preparadas, especialmente despois do lanzamento de Selenium grid 4 cunha arquitectura interna modificada.
Selenoide:
A implantación de selenoides en K8 é actualmente a maior decepción. Non son compatibles. En teoría, podemos levantar un contedor Selenoid dentro dunha cápsula, pero cando Selenoid comece a lanzar contedores con navegadores, seguirán estando dentro da mesma cápsula. Isto fai que a escala sexa imposible e, como resultado, o traballo de Selenoid dentro dun clúster non será diferente do traballo dentro dunha máquina virtual. Fin da historia.
lúa:
Coñecendo este pescozo de botella ao traballar con Selenoid, os desenvolvedores lanzaron unha ferramenta máis poderosa chamada Moon. Esta ferramenta foi deseñada orixinalmente para funcionar con Kubernetes e, como resultado, a función de escalado automático pode e debe usarse. Ademais, diría que de momento é así o único unha ferramenta no mundo de Selenium, que ten soporte nativo de clúster K8s fóra da caixa (xa non está dispoñible, consulte a seguinte ferramenta ). As principais características de Moon que proporcionan este soporte son:
Completamente apátrida. Selenoid almacena na memoria información sobre as sesións do navegador en execución. Se por algún motivo o seu proceso falla, pérdense todas as sesións en execución. Pola contra, Moon non ten estado interno e pódese replicar en centros de datos. As sesións do navegador permanecen vivas aínda que unha ou máis réplicas caian.
Entón, Moon é unha gran solución, pero hai un problema: non é gratuíto. O prezo depende do número de sesións. Só podes realizar de 0 a 4 sesións de balde, o que non é especialmente útil. Pero, a partir da quinta sesión, terás que pagar 5 dólares por cada un. A situación pode diferir dunha empresa a outra, pero no noso caso, usar Moon non ten sentido. Como describín anteriormente, podemos executar máquinas virtuales con Selenium Grid baixo demanda ou aumentar o número de nodos no clúster. Para aproximadamente un pipeline, lanzamos 500 navegadores e detemos todos os recursos despois de que se completen as probas. Se utilizamos Moon, teriamos que pagar 500 x 5 = 2500 dólares ao mes, sen importar a frecuencia con que realicemos probas. De novo, non digo que non uses Moon. Para as túas tarefas, esta pode ser unha solución indispensable, por exemplo, se tes moitos proxectos/equipos na túa organización e necesitas un enorme clúster común para todos. Como sempre, deixo un enlace ao final e recomendo facer todos os cálculos necesarios no contexto da súa tarefa.
Calisto: (Atención! Isto non está no artigo orixinal e só está contido na tradución rusa)
Como dixen, Selenium é unha ferramenta moi popular e o campo das TI está a desenvolverse moi rapidamente. Mentres traballaba na tradución, apareceu na web unha nova ferramenta prometedora chamada Callisto (ola Cypress e outros asasinos de selenio). Funciona de forma nativa con K8s e permítelle executar contedores Selenoid en pods, distribuídos entre nós. Todo funciona desde o primeiro momento, incluído o escalado automático. Fantástico, pero hai que probalo. Xa conseguín implantar esta ferramenta e realizar varios experimentos. Pero é cedo para sacar conclusións, despois de recibir resultados a longa distancia, quizais faga unha revisión en artigos futuros. Polo momento só deixo ligazóns para investigacións independentes.
Ilustración do estado actual das infraestruturas
Ligazóns para explorar
Ferramentas semellantes
7. Infraestrutura como código (IaC)
Breve descrición da tecnoloxía
E agora chegamos ao último apartado. Normalmente, esta tecnoloxía e as tarefas relacionadas non son responsabilidade dos enxeñeiros de automatización. E hai razóns para iso. En primeiro lugar, en moitas organizacións, os problemas de infraestrutura están baixo o control do departamento de DevOps e aos equipos de desenvolvemento non lles importa realmente o que fai que o pipeline funcione e como hai que apoiar todo o relacionado con el. En segundo lugar, sexamos sinceros, a práctica da Infraestrutura como Código (IaC) aínda non está adoptada en moitas empresas. Pero definitivamente converteuse nunha tendencia popular e é importante tratar de implicarse nos procesos, enfoques e ferramentas asociados a ela. Ou polo menos estar ao día.
Comecemos coa motivación para usar este enfoque. Xa comentamos que para realizar probas en GitlabCI, necesitaremos como mínimo os recursos para executar Gitlab Runner. E para executar contedores con navegadores/emuladores, necesitamos reservar unha máquina virtual ou un clúster. Ademais dos recursos de proba, necesitamos unha cantidade importante de capacidade para soportar o desenvolvemento, a posta en escena, os contornos de produción, que tamén inclúen bases de datos, programacións automáticas, configuracións de rede, equilibradores de carga, dereitos de usuario, etc. A cuestión fundamental é o esforzo necesario para apoialo todo. Hai varias formas de facer cambios e lanzar actualizacións. Por exemplo, no contexto de GCP, podemos usar a consola da IU no navegador e realizar todas as accións facendo clic nos botóns. Unha alternativa sería utilizar chamadas de API para interactuar coas entidades da nube ou utilizar a utilidade de liña de comandos gcloud para realizar as manipulacións desexadas. Pero cun número realmente grande de entidades e elementos de infraestrutura diferentes, faise difícil ou mesmo imposible realizar todas as operacións manualmente. Ademais, todas estas accións manuais son incontrolables. Non podemos envialos para a súa revisión antes da execución, usar un sistema de control de versións e retrotraer rapidamente os cambios que provocaron o incidente. Para resolver estes problemas, os enxeñeiros crearon e crearon scripts bash/shell automáticos, que non son moito mellores que os métodos anteriores, xa que non son tan fáciles de ler, comprender, manter e modificar rapidamente nun estilo de procedemento.
Neste artigo e como guía, uso 2 ferramentas relacionadas coa práctica de IaC. Estes son Terraform e Ansible. Algunhas persoas cren que non ten sentido usalos ao mesmo tempo, xa que a súa funcionalidade é similar e son intercambiables. Pero o caso é que inicialmente se lles encargan tarefas completamente diferentes. E o feito de que estas ferramentas deberían complementarse foi confirmado nunha presentación conxunta dos desenvolvedores que representan a HashiCorp e RedHat. A diferenza conceptual é que Terraform é unha ferramenta de aprovisionamento para xestionar os propios servidores. Mentres que Ansible é unha ferramenta de xestión de configuración cuxa tarefa é instalar, configurar e xestionar software nestes servidores.
Outra característica distintiva destas ferramentas é o estilo de codificación. A diferenza de bash e Ansible, Terraform usa un estilo declarativo baseado nunha descrición do estado final desexado que se conseguirá como resultado da execución. Por exemplo, se imos crear 10 máquinas virtuales e aplicar os cambios a través de Terraform, obteremos 10 máquinas virtuales. Se executamos de novo o script, non pasará nada xa que xa temos 10 máquinas virtuales, e Terraform sábeo porque almacena o estado actual da infraestrutura nun ficheiro de estado. Pero Ansible usa un enfoque de procedemento e, se lle pide que cree 10 máquinas virtuales, no primeiro lanzamento obteremos 10 máquinas virtuales, semellantes a Terraform. Pero despois de reiniciar xa teremos 20 máquinas virtuales. Esta é a diferenza importante. No estilo de procedemento, non almacenamos o estado actual e simplemente describimos unha secuencia de pasos que se deben realizar. Por suposto, podemos manexar diversas situacións, engadir varias comprobacións da existencia de recursos e do estado actual, pero non serve de nada perder o tempo e esforzarnos en controlar esta lóxica. Ademais, isto aumenta o risco de cometer erros.
Resumindo todo o anterior, podemos concluír que Terraform e a notación declarativa son unha ferramenta máis adecuada para aprovisionar servidores. Pero é mellor delegar o traballo da xestión da configuración en Ansible. Con iso fóra do camiño, vexamos casos de uso no contexto da automatización.
Valor para a infraestrutura de automatización
O único importante que hai que entender aquí é que a infraestrutura de automatización de probas debe considerarse como parte de toda a infraestrutura da empresa. Isto significa que todas as prácticas de IaC deben aplicarse globalmente aos recursos de toda a organización. Quen é o responsable disto depende dos teus procesos. O equipo de DevOps ten máis experiencia nestes problemas, ven toda a imaxe do que está a suceder. Non obstante, os enxeñeiros de control de calidade están máis implicados no proceso de automatización do edificio e na estrutura do gasoduto, o que lles permite ver mellor todos os cambios necesarios e as oportunidades de mellora. A mellor opción é traballar xuntos, intercambiar coñecementos e ideas para acadar o resultado esperado.
Aquí tes algúns exemplos de uso de Terraform e Ansible no contexto da automatización de probas e as ferramentas que comentamos antes:
1. Describe as características e parámetros necesarios das máquinas virtuales e clústeres mediante Terraform.
2. Usando Ansible, instala as ferramentas necesarias para probar: docker, Selenoid, Selenium Grid e descarga as versións necesarias dos navegadores/emuladores.
3. Usando Terraform, describa as características da máquina virtual na que se lanzará GitLab Runner.
4. Instala GitLab Runner e as ferramentas necesarias que o acompañan mediante Ansible, establece axustes e configuracións.
Ilustración do estado actual das infraestruturas
Ligazóns para explorar:
Ferramentas semellantes
Imos resumir!
Paso
tecnoloxía
ferramentas
Valor para a infraestrutura de automatización
1
Carreira local
Node.js, Selenium, Appium
- As ferramentas máis populares para web e móbil
- Admite moitos idiomas e plataformas (incluíndo Node.js)
2
Sistemas de control de versións
ir
- Beneficios similares co código de desenvolvemento
3
Containerización
Docker, Selenium grid, Selenoid (Web, Android)
- Realización de probas en paralelo
- Ambientes illados
- Actualizacións de versión sinxelas e flexibles
- Deter dinámicamente os recursos non utilizados
- Fácil de configurar
4
CI/CD
Gitlab CI
- Proba parte da canalización
- Comentarios rápidos
- Visibilidade para toda a empresa/equipo
5
Plataformas na nube
Google Cloud Platform
- Recursos baixo demanda (pagamos só cando sexa necesario)
- Fácil de xestionar e actualizar
- Visibilidade e control de todos os recursos
6
Orquestración
Kubernetes
No contexto de contedores con navegadores/emuladores dentro de pods:
- Escalado/escalado automático
- Autocuración
- Actualizacións e retrocesos sen interrupcións
7
Infraestrutura como código (IaC)
Terraform, Ansible
- Beneficios similares coas infraestruturas de desenvolvemento
- Todas as vantaxes da versión de código
- Fácil de facer cambios e manter
- Totalmente automatizado
Diagramas de mapa mental: evolución da infraestrutura
Paso 1: Local
Paso 2: VCS
Paso 3: Containerización
Paso 4: CI/CD
Paso 5: Plataformas na nube
Paso 6: Orquestración
Paso 7: IaC
Cal é o próximo?
Entón, este é o final do artigo. Pero en conclusión, gustaríame establecer algúns acordos con vostede.
Do teu lado
Como dixen ao principio, gustaríame que o artigo fose de utilidade práctica e che axudase a aplicar os coñecementos adquiridos no traballo real. Engado de novo.
Pero aínda despois, non te pares, practica, estuda enlaces e libros relevantes, descubre como funciona na túa empresa, atopa lugares que se poidan mellorar e participa nel. Moita sorte!
Do meu lado
Polo título pódese ver que esta era só a primeira parte. A pesar de que resultou ser bastante grande, aquí aínda non se tratan temas importantes. Na segunda parte, penso analizar a infraestrutura de automatización no contexto de IOS. Debido ás restricións de Apple para executar simuladores iOS só en sistemas macOS, a nosa gama de solucións está reducida. Por exemplo, non podemos usar Docker para executar o simulador nin as nubes públicas para executar máquinas virtuais. Pero isto non significa que non haxa outras alternativas. Tentarei mantelo actualizado con solucións avanzadas e ferramentas modernas!
Ademais, non mencionei temas moi grandes relacionados co seguimento. Na parte 3, vou ver as ferramentas de monitorización de infraestruturas máis populares e que datos e métricas hai que ter en conta.
E finalmente. No futuro, penso lanzar un curso de vídeo sobre a construción de infraestruturas de proba e ferramentas populares. Actualmente, hai bastantes cursos e conferencias sobre DevOps en Internet, pero todos os materiais preséntanse no contexto do desenvolvemento, non da automatización das probas. Neste tema, realmente necesito comentarios sobre se tal curso será interesante e valioso para a comunidade de probadores e enxeñeiros de automatización. Grazas por adiantado!
Fonte: www.habr.com