Get best of the week

Las herramientas DevOps no son solo para DevOps. El proceso de construir una infraestructura de automatización de prueba desde cero

Parte 1: Web / Android


Nota : este artículo es una traducción al ruso del artículo original  “Las herramientas DevOps no son solo para DevOps. Creación de infraestructura de automatización de prueba desde cero ". Sin embargo, todas las ilustraciones, enlaces, citas y términos se almacenan en el idioma original para evitar distorsiones de significado cuando se traducen al ruso. ¡Te deseo un estudio agradable!



Actualmente, la especialidad DevOps es una de las más populares en la industria de TI. Si abre sitios populares de búsqueda de empleo y establece un filtro de salario, verá que los trabajos relacionados con DevOps se encuentran en la parte superior de la lista. Sin embargo, es importante entender que esto se refiere principalmente a la posición de 'Senior', lo que implica que el candidato tiene un alto nivel de habilidades, conocimiento de tecnologías y herramientas. También viene con un alto grado de responsabilidad asociado con el buen funcionamiento de la producción. Sin embargo, comenzamos a olvidar lo que es DevOps. Inicialmente, no era una persona o departamento específico. Si buscamos las definiciones de este término, encontraremos muchos sustantivos hermosos y correctos, como metodología, prácticas, filosofía cultural, un grupo de conceptos, etc.

Mi especialización es un ingeniero de automatización de control de calidad, pero creo que no solo debe estar relacionado con la escritura de pruebas automáticas o el desarrollo de una arquitectura para un marco de prueba. En 2020, también se necesita conocimiento de la infraestructura de automatización. Esto le permite organizar el proceso de automatización usted mismo, desde el lanzamiento de las pruebas hasta la provisión de resultados a todas las partes interesadas de acuerdo con los objetivos. Como resultado, las habilidades de DevOps son imprescindibles para este trabajo. Y todo esto es bueno, pero, desafortunadamente, hay un problema ( spoiler: este artículo intenta simplificar este problema)) Se basa en el hecho de que DevOps es complicado. Y esto es obvio, porque las empresas no pagarán mucho por lo que es fácil de hacer ... En el mundo de DevOps hay una gran cantidad de herramientas, términos y prácticas que deben dominarse. Esto es especialmente difícil al comienzo de una carrera y depende de la experiencia técnica acumulada.


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

Aquí, probablemente completaremos la parte introductoria y nos centraremos en el propósito de este artículo. 

De qué se trata este artículo


En este artículo voy a compartir mi experiencia en la construcción de una infraestructura de automatización de prueba. En Internet puede encontrar muchas fuentes de información sobre diversas herramientas y cómo usarlas, pero me gustaría considerarlas exclusivamente en el contexto de la automatización. Creo que muchos ingenieros de automatización están familiarizados con una situación en la que nadie ejecuta las pruebas desarrolladas, excepto usted mismo, y no le importa su soporte. Como resultado, las pruebas se vuelven obsoletas y debe dedicar tiempo a actualizarlas. Nuevamente, al comienzo de una carrera, esta puede ser una tarea bastante difícil: decidir correctamente qué herramientas deberían ayudar a resolver este problema, cómo elegirlas, configurarlas y mantenerlas. Algunos probadores piden ayuda a DevOps (personas) y, para ser sincero, este enfoque funciona.En muchos casos, esta puede ser la única opción, ya que no tenemos la visibilidad de todas las dependencias. Pero, como sabemos, DevOps son personas muy ocupadas, porque deberían pensar en la infraestructura de toda la empresa, la implementación, el monitoreo, los microservicios y otras tareas similares dependiendo de la organización / equipo. Como suele suceder, la automatización no es una prioridad. En este caso, debemos tratar de hacer nuestro mejor esfuerzo desde el principio hasta el final. Esto reducirá las adicciones, acelerará el flujo de trabajo, mejorará nuestras habilidades y nos permitirá ver una imagen más amplia de lo que está sucediendo.microservicios y otras tareas similares dependiendo de la organización / equipo. Como suele suceder, la automatización no es una prioridad. En este caso, debemos tratar de hacer nuestro mejor esfuerzo desde el principio hasta el final. Esto reducirá las adicciones, acelerará el flujo de trabajo, mejorará nuestras habilidades y nos permitirá ver una imagen más amplia de lo que está sucediendo.microservicios y otras tareas similares dependiendo de la organización / equipo. Como suele suceder, la automatización no es una prioridad. En este caso, debemos tratar de hacer nuestro mejor esfuerzo desde el principio hasta el final. Esto reducirá las adicciones, acelerará el flujo de trabajo, mejorará nuestras habilidades y nos permitirá ver una imagen más amplia de lo que está sucediendo.

El artículo presenta las herramientas más populares y populares y muestra cómo usarlas para la construcción paso a paso de la infraestructura de automatización. Cada grupo está representado por herramientas que han sido probadas en experiencia personal. Pero esto no significa que deba usar lo mismo. Las herramientas en sí mismas no son importantes, aparecen y se vuelven obsoletas. Nuestra tarea de ingeniería es comprender los principios básicos: por qué necesitamos este grupo de herramientas y qué tareas de trabajo podemos resolver con su ayuda. Por lo tanto, al final de cada sección, dejo enlaces a herramientas similares que pueden usarse en su organización.

Lo que no está en este artículo


Una vez más, el artículo no trata sobre herramientas específicas, por lo que no habrá inserciones de código de la documentación y descripciones de comandos específicos. Pero al final de cada sección, dejo enlaces para un estudio detallado.

Esto se debe al hecho de que: 

  • este material es muy fácil de encontrar en varias fuentes (documentación, libros, video cursos);
  • si comenzamos a profundizar, tendremos que escribir 10, 20, 30 partes de este artículo (mientras que los planes 2-3);
  • Simplemente no quiero perder su tiempo, porque tal vez quiera usar otras herramientas para lograr los mismos objetivos.

Práctica


Realmente me gustaría que este material sea útil para todos los lectores, y no solo para ser leído y olvidado. En cualquier estudio, la práctica es un componente muy importante. Para hacer esto, preparé un repositorio de GitHub con una guía paso a paso sobre cómo hacer todo desde cero . También estará esperando la tarea para asegurarse de no haber copiado sin pensar líneas de comandos ejecutados

Plan


PasoTecnologíaHerramientas
1Ejecución local (prepare pruebas de demostración web / android y ejecútelo localmente) Node.js, Selenium, Appium
2Sistemas de control de versiones Git
3ContenedorizaciónDocker, Selenium grid, Selenoid (Web, Android)
4 4CI / CDGitlab ci
5 5Plataformas en la nubePlataforma en la nube de Google
6 6OrquestaciónKubernetes
7 7Infraestructura como código (IaC)Terraform, ansible

La estructura de cada sección.


Para mantener la narrativa en forma visual, cada sección se describe de la siguiente manera:

  • ,
  • ,
  • ,
  • ,
  • .

1.



Este es solo un paso preparatorio para ejecutar las pruebas de demostración localmente y verificar que pasen con éxito. En la parte práctica, se usa Node.js, pero el lenguaje de programación y la plataforma tampoco son importantes y puede usar los que se usan en su empresa. 

Sin embargo, como herramienta de automatización, recomiendo usar Selenium WebDriver para plataformas web y Appium para la plataforma Android, respectivamente, ya que en los próximos pasos usaremos imágenes de Docker que están específicamente diseñadas para funcionar específicamente con estas herramientas. Además, en referencia a los requisitos en vacantes, estas herramientas son las más demandadas en el mercado.

Como habrás notado, solo consideramos las pruebas web y de Android. Desafortunadamente, iOS es una historia completamente diferente (gracias a Apple). Planeo demostrar las soluciones y prácticas relacionadas con iOS en las siguientes partes.

Valor para la infraestructura de automatización.


Desde el punto de vista de la infraestructura, un lanzamiento local no tiene ningún valor. Solo verifica que las pruebas se ejecuten en la máquina local en navegadores y simuladores locales. Pero en cualquier caso, este es un punto de partida necesario.

Ilustración del estado actual de la infraestructura.




Enlaces de aprendizaje



Herramientas similares


  • cualquier lenguaje de programación que le guste junto con Selenium / Appium - tests;
  • cualquier prueba;
  • cualquier corredor de prueba.

2. Sistemas de control de versiones (Git)


Resumen de tecnología


No será un gran descubrimiento para nadie si digo que el sistema de control de versiones es una parte extremadamente importante del desarrollo tanto en equipo como individualmente. Basado en varias fuentes, podemos decir con confianza que Git es el representante más popular. El sistema de control de versiones ofrece muchas ventajas, como el intercambio de código, el almacenamiento de versiones, la restauración a sucursales anteriores, el monitoreo del historial del proyecto, las copias de seguridad. No discutiremos cada artículo en detalle, ya que estoy seguro de que está familiarizado con esto y lo usará en el trabajo diario. Pero si de repente no, entonces recomiendo pausar la lectura de este artículo y llenar este vacío lo antes posible.

Valor para la infraestructura de automatización.


Y aquí puedes hacer una pregunta razonable: “¿Por qué nos cuenta sobre Git? Todo el mundo lo sabe y lo usa tanto para el código de desarrollo como para el código de prueba automática ". Tendrá toda la razón, pero en este artículo estamos hablando de infraestructura y esta sección desempeña el papel de una vista previa de la sección 7: "Infraestructura como código (IaC)". Para nosotros, esto significa que toda la infraestructura, incluida la de prueba, se describe en forma de código, por lo que también podemos aplicarle sistemas de versiones y obtener ventajas similares tanto para el código de desarrollo como para el de automatización.

Analizaremos IaC con más detalle en el paso 7, pero incluso ahora puede comenzar a usar Git localmente creando un repositorio local. El panorama general se ampliará cuando agreguemos un repositorio remoto a la infraestructura.

Ilustración del estado actual de la infraestructura.




Enlaces de aprendizaje



Herramientas similares



3. Contenedorización (Docker)


Resumen de tecnología


Para demostrar cómo la contenedorización cambió las reglas del juego, retrocedamos varias décadas. En aquellos días, la gente compraba y usaba máquinas de servidor para ejecutar aplicaciones. Pero en la mayoría de los casos, los recursos requeridos necesarios para el lanzamiento no se conocían de antemano. Como resultado, las empresas gastaron dinero en la compra de servidores potentes y caros, pero algunas de estas capacidades no se utilizaron por completo.

La siguiente etapa de la evolución fueron las máquinas virtuales (VM), que resolvieron el problema de gastar dinero en recursos no utilizados. Esta tecnología hizo posible ejecutar aplicaciones de forma independiente dentro del mismo servidor, asignando un espacio completamente aislado. Pero, desafortunadamente, cualquier tecnología tiene sus inconvenientes. Iniciar una VM requiere un sistema operativo completo que consuma CPU, RAM, almacenamiento y, según el sistema operativo, debe considerar el costo de una licencia. Estos factores afectan la velocidad de descarga y complican la portabilidad.

Y así llegamos a la contenedorización. Y nuevamente, esta tecnología resolvió el problema anterior, ya que los contenedores no utilizan un sistema operativo completo, lo que libera una gran cantidad de recursos y proporciona una solución rápida y flexible para la portabilidad.

Por supuesto, la tecnología de contenedorización no es nueva y se introdujo por primera vez a finales de los años 70. En aquellos días, había mucha investigación, trabajo preliminar e intentos. Pero fue Docker quien adaptó esta tecnología y la hizo fácilmente accesible para las masas. Hoy en día, cuando hablamos de contenedores, en la mayoría de los casos nos referimos a Docker. Cuando hablamos de contenedores Docker, nos referimos a contenedores Linux. Podemos usar sistemas Windows y macOS para ejecutar contenedores, pero es importante comprender que en este caso aparece una capa adicional. Por ejemplo, Docker en una Mac lanza silenciosamente contenedores dentro de una máquina virtual Linux liviana. Volveremos a este tema cuando discutamos el lanzamiento de emuladores de Android dentro de contenedores, y aquí es donde aparece un matiz muy importante, que debe analizarse con más detalle.

Valor para la infraestructura de automatización.


Descubrimos que la contenedorización y Docker son geniales. Miremos esto en el contexto de la automatización, porque cada herramienta o tecnología debería resolver un problema. Denotemos los problemas obvios de la automatización de pruebas en el contexto de las pruebas de IU:

  • una gran cantidad de dependencias al instalar Selenium y especialmente Appium;
  • problemas de compatibilidad entre versiones de navegadores, simuladores y controladores;
  • falta de espacio aislado para navegadores / simuladores, lo cual es especialmente crítico para el lanzamiento paralelo;
  • Es difícil de administrar y mantener si necesita ejecutar 10, 50, 100 o incluso 1000 navegadores al mismo tiempo.

Pero dado que Selenium es la herramienta de automatización más popular, y Docker es la herramienta de contenedorización más popular, no debería sorprender a nadie que alguien haya intentado combinarlas para obtener una herramienta poderosa para resolver los problemas anteriores. Consideremos tales soluciones con más detalle. 

Rejilla de selenio en la ventana acoplable

Esta herramienta es la más popular en el mundo de Selenium para lanzar y administrar múltiples navegadores en múltiples máquinas desde un sitio central. Para comenzar, debe registrar al menos 2 partes: Hub y Nodo (s). Un concentrador es un sitio central que recibe todas las solicitudes de las pruebas y las distribuye a los nodos apropiados. Para cada nodo, podemos configurar una configuración específica, por ejemplo, especificando el navegador deseado y su versión. Sin embargo, aún debemos ocuparnos de los controladores de navegador compatibles e instalarlos en los nodos necesarios. Por esta razón, la grilla Selenium no se usa en su forma pura, excepto cuando necesitamos trabajar con navegadores que no se pueden instalar en el sistema operativo Linux.Para todos los demás casos, usar una imagen Docker para ejecutar el Selenium grid Hub and Nodes es una solución mucho más flexible y correcta. Este enfoque simplifica enormemente la administración de nodos, ya que podemos elegir la imagen que necesitamos con versiones compatibles ya instaladas de navegadores y controladores.

A pesar de los comentarios negativos sobre la estabilidad, especialmente cuando se ejecuta una gran cantidad de nodos en paralelo, la cuadrícula de selenio sigue siendo la herramienta más popular para ejecutar pruebas de selenio en paralelo. Es importante tener en cuenta que en el código abierto aparecen constantemente varias mejoras y modificaciones de esta herramienta que luchan con varios cuellos de botella.

Selenoid para web

Esta herramienta es un gran avance en el mundo de Selenium, ya que funciona de forma inmediata y ha hecho la vida de muchos ingenieros de automatización mucho más fácil. En primer lugar, esta no es otra modificación de la cuadrícula de selenio. En cambio, los desarrolladores crearon una versión completamente nueva de Selenium Hub en el lenguaje Golang, que, junto con las imágenes ligeras de Docker para varios navegadores, impulsó el desarrollo de la automatización de pruebas. Además, en el caso de Selenium Grid, debemos determinar de antemano todos los navegadores necesarios y sus versiones, lo que no es un problema cuando se trabaja con un solo navegador. Pero cuando se trata de varios navegadores compatibles, Selenoid es la solución número uno, gracias a la función 'navegador a pedido'. Todo lo que se requiere de nosotros es precargar las imágenes necesarias con los navegadores y actualizar el archivo de configuración,con el que interactúa Selenoid. Después de que Selenoid recibe una solicitud de las pruebas, iniciará automáticamente el contenedor correcto con el navegador correcto. Cuando finalice la prueba, Selenoid soltará el contenedor, liberando recursos para las siguientes consultas. Este enfoque elimina por completo el conocido problema de 'degradación de nodos', que a menudo vemos en la cuadrícula de selenio.

Pero, por desgracia, Selenoid todavía no es una bala de plata. Tenemos la función de navegador a pedido, pero la función de recursos a pedido todavía no está disponible. Para usar Selenoid, debemos implementarlo en un hardware físico o VM, lo que significa que necesitamos saber de antemano cuántos recursos deben asignarse. Creo que esto no es un problema para pequeños proyectos que ejecutan 10, 20 o incluso 30 navegadores en paralelo. Pero, ¿qué pasa si necesitamos 100, 500, 1000 y más? No tiene sentido mantener y pagar tantos recursos todo el tiempo. En las secciones 5 y 6 de este artículo, discutiremos soluciones que le permiten escalar, reduciendo significativamente los costos de la compañía.

Selenoid para Android

Después del éxito de Selenoid como herramienta para la automatización web, la gente quería obtener algo similar para Android. Y sucedió: Selenoid fue lanzado con soporte para Android. Desde una perspectiva de usuario de alto nivel, el principio de funcionamiento es similar a la automatización web. La única diferencia es que, en lugar de contenedores con navegadores, Selenoid lanza contenedores con emuladores de Android. En mi opinión, hoy es la herramienta gratuita más poderosa para ejecutar pruebas de Android en paralelo.

Realmente no me gustaría hablar sobre los aspectos negativos de esta herramienta, ya que realmente me gusta mucho. Pero aún existen los mismos inconvenientes relacionados con la automatización web relacionados con el escalado. Además de esto, necesitamos hablar sobre otra limitación, que puede ser una sorpresa si afinamos el instrumento por primera vez. Para ejecutar imágenes de Android, necesitamos una máquina física o VM con soporte de virtualización anidada. En la guía práctica, demuestro cómo activar esto en una máquina virtual Linux. Sin embargo, si es un usuario de macOS y desea implementar Selenoid localmente, no será posible ejecutar pruebas de Android. Pero siempre puede iniciar la máquina virtual Linux localmente con la 'virtualización anidada' configurada e implementar Selenoid en su interior.

Ilustración del estado actual de la infraestructura.


En el contexto de este artículo, agregaremos 2 herramientas para ilustrar la infraestructura. Estos son Selenium grid para pruebas web y Selenoid para pruebas de Android. En el manual de GitHub, también mostraré cómo usar Selenoid para ejecutar pruebas web. 



Enlaces de aprendizaje



Herramientas similares


  • Existen otras herramientas de contenedorización, pero Docker es la más popular. Si desea probar otra cosa, tenga en cuenta que las herramientas que revisamos para ejecutar las pruebas de Selenium en paralelo no funcionarán de inmediato.  
  • Como ya se mencionó, hay muchas modificaciones de la cuadrícula de selenio, por ejemplo, Zalenium .

4. CI / CD


Resumen de tecnología


La práctica de la integración continua es bastante popular en el desarrollo y está a la par con los sistemas de control de versiones. A pesar de esto, siento que hay confusión en la terminología. En esta sección, me gustaría describir 3 modificaciones de esta tecnología desde mi punto de vista. En Internet puede encontrar muchos artículos con diferentes interpretaciones, y es absolutamente normal si su opinión es diferente. Lo más importante es que estás en la misma longitud de onda que tus colegas.

Entonces, hay 3 términos: CI: integración continua (CD), CD: entrega continua (CD) y nuevamente CD: implementación continua (CD). ( Además usaré estos términos en inglés) Cada modificación agrega algunos pasos adicionales a su canal de desarrollo. Pero la palabra continua es la más importante. En este contexto, queremos decir algo que sucede de principio a fin, sin interrupción o exposición manual. Echemos un vistazo a CI y CD y CD en este contexto.

  • La integración continua es el paso inicial en la evolución. Después de enviar el nuevo código al servidor, esperamos recibir una respuesta rápida de que todo está en orden con nuestros cambios. Típicamente, CI incluye el lanzamiento de herramientas de análisis de código estático y pruebas de unidad / API internas. Esto le permite obtener información sobre nuestro código unos segundos / minutos más tarde.
  • Continuous Delivery , /UI-. , CI. -, . -, test/staging — . , , .
  • Continuous Deployment , (release) production, . release , smoke — production . Continuous Deployment . - , , Continuous (). , Continuous Delivery.


En esta sección, debo aclarar que cuando hablamos de pruebas de interfaz de usuario de extremo a extremo, esto implica que debemos implementar nuestros cambios y servicios relacionados en los entornos de prueba. Integración continua: el proceso no es aplicable para esta tarea y debemos tener cuidado de implementar al menos prácticas de entrega continua. La implementación continua también tiene sentido en el contexto de las pruebas de IU si vamos a ejecutarlas en producción.

Y antes de ver la ilustración del cambio de arquitectura, quiero decir algunas palabras sobre GitLab CI. A diferencia de otras herramientas de CI / CD, GitLab proporciona un repositorio remoto y muchas otras características avanzadas. Entonces GitLab es más que CI. Incluye control de origen listo para usar, administración ágil, canalizaciones de CI / CD, herramientas de registro y recopilación de métricas. La arquitectura de GitLab consta de Gitlab CI / CD y GitLab Runner. Doy una breve descripción del sitio oficial:
Gitlab CI / CD es una aplicación web con una API que almacena su estado en una base de datos, gestiona proyectos / compilaciones y proporciona una interfaz de usuario. GitLab Runner es una aplicación que procesa compilaciones. Se puede implementar por separado y funciona con GitLab CI / CD a través de una API. Para las pruebas en ejecución, necesita tanto la instancia de Gitlab como Runner.








5.



En esta sección, hablaremos sobre una tendencia popular llamada 'nubes públicas'. A pesar de los enormes beneficios que proporcionan las tecnologías de virtualización y contenedorización descritas anteriormente, aún necesitamos recursos informáticos. Las empresas compran servidores caros o alquilan centros de datos, pero en este caso es necesario hacer cálculos (a veces poco realistas) de cuántos recursos necesitaremos, si los usaremos las 24 horas del día, los 7 días de la semana y para qué fines. Por ejemplo, la producción requiere un servidor que funcione las veinticuatro horas del día, pero ¿necesitamos recursos similares para realizar las pruebas después de horas? También depende del tipo de prueba que se realice. Un ejemplo serían las pruebas de estrés / estrés, que planeamos ejecutar después de horas para obtener resultados al día siguiente. Pero definitivamenteLa disponibilidad del servidor de 24 horas no es necesaria para las pruebas automáticas de extremo a extremo, y especialmente para entornos de pruebas manuales. Para tales situaciones, sería bueno recibir tantos recursos como sea necesario a pedido, usarlos y dejar de pagar cuando ya no sean necesarios. Además, sería bueno recibirlos instantáneamente haciendo unos pocos clics del mouse o ejecutando un par de scripts. Para esto, se utilizan nubes públicas. Veamos la definición:Para esto, se utilizan nubes públicas. Veamos la definición:Para esto, se utilizan nubes públicas. Veamos la definición:
“La nube pública se define como los servicios informáticos ofrecidos por proveedores externos a través de Internet pública, que los ponen a disposición de cualquier persona que quiera usarlos o comprarlos. "Pueden ser gratuitos o vendidos a pedido, lo que permite a los clientes pagar solo por uso por los ciclos de CPU, el almacenamiento o el ancho de banda que consumen".

Existe la opinión de que las nubes públicas son caras. Pero su idea clave es reducir los costos de la compañía. Como se mencionó anteriormente, las nubes públicas le permiten obtener recursos a pedido y pagar solo por el tiempo que se utilizan. Además, a veces olvidamos que a los empleados se les paga, y los especialistas también son un recurso costoso. Tenga en cuenta que las nubes públicas facilitan enormemente el soporte de infraestructura, lo que permite a los ingenieros centrarse en tareas más importantes. 

Valor para la infraestructura de automatización.


¿Qué recursos específicos necesitamos para las pruebas de interfaz de usuario de extremo a extremo? Estas son principalmente máquinas virtuales o clústeres (hablaremos de Kubernetes en la siguiente sección) para lanzar navegadores y emuladores. Cuantos más navegadores y emuladores queramos ejecutar al mismo tiempo, se necesitará más CPU y memoria y más dinero tendremos que pagar por ello. Por lo tanto, las nubes públicas en el contexto de la automatización de pruebas nos permiten lanzar una gran cantidad (100, 200, 1000 ...) de navegadores / emuladores a pedido, obtener resultados de las pruebas lo más rápido posible y dejar de pagar por esas capacidades increíblemente intensivas en recursos. 

Los proveedores de nube más populares son Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP). La guía práctica proporciona ejemplos del uso de GCP, pero en general no importa lo que use para las tareas de automatización. Todos ellos proporcionan aproximadamente la misma funcionalidad. Por lo general, para seleccionar un proveedor, la administración se enfoca en toda la infraestructura y los requisitos comerciales de la compañía, que están más allá del alcance de este artículo. Será más interesante para los ingenieros de automatización comparar el uso de proveedores en la nube que usan plataformas en la nube específicamente para fines de prueba como Sauce Labs, BrowserStack, BitBar, etc. ¡Entonces hagamos lo mismo! En mi opinión, Sauce Labs es la granja de pruebas en la nube más famosa, por lo que la tomé para comparar. 

GCP vs. Sauce Labs for Automation:

imagine que necesitamos ejecutar 8 pruebas web y 8 pruebas de Android al mismo tiempo. Para hacer esto, usaremos GCP y ejecutaremos 2 máquinas virtuales con Selenoid. En el primero levantaremos 8 contenedores con navegadores. En el segundo - 8 contenedores con emuladores. Echemos un vistazo a los precios:  


Para ejecutar un contenedor con Chrome, necesitamos una máquina n1-standard-1 . En el caso de Android, este será n1-standard-4 para un emulador. De hecho, una forma más flexible y económica es establecer valores de usuario específicos para CPU / Memoria, pero por el momento no es importante para la comparación con Sauce Labs.

Y aquí están las tarifas para usar Sauce Labs:


Supongo que ya ha notado la diferencia, pero aún así le daré una tabla con los cálculos para nuestra tarea:

Recursos necesariosMontlyHorario de trabajo (8 am - 8 pm)Horas de trabajo + Preemptible
Gcp para webn1-estándar-1 x 8 = n1-estándar-8$ 194.1823 días * 12h * 0.38 = 104.88 $ 23 días * 12h * 0.08 = 22.08 $
Sauce Labs para WebPruebas paralelas de Virtual Cloud8$ 1.559--
GCP para Androidn1-estándar-4 x 8: n1-estándar-16$ 776.7223 días * 12h * 1.52 = $ 419.52 23 días * 12h * 0.32 = 88.32 $
Sauce Labs para AndroidPruebas paralelas de Real Device Cloud 8$ 1.999--

Como puede ver, la diferencia en el costo es enorme, especialmente si ejecuta las pruebas solo en el período de trabajo de doce horas. Pero puede reducir aún más los costos utilizando máquinas con prioridad. ¿Qué es?
A preemptible VM is an instance that you can create and run at a muchower price than normal instances. However, Compute Engine might terminate (preempt) these instances if it requires access to those resources for other tasks. Preemptible instances are excess Compute Engine capacity, so their availability varies with usage.

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

¡Y este todavía no es el final! De hecho, estoy seguro de que nadie realiza pruebas durante 12 horas sin descanso. Y si es así, puede iniciar y detener automáticamente las máquinas virtuales cuando no sean necesarias. El tiempo de uso real puede caer a 6 horas por día. Luego, el pago en el contexto de nuestra tarea disminuirá hasta $ 11 por mes para 8 navegadores. ¿No es eso perfecto? Pero con las máquinas con prioridad, debemos ser cuidadosos y estar preparados para las interrupciones y el funcionamiento inestable, aunque estas situaciones se pueden proporcionar y procesar mediante programación. ¡Vale la pena!

Pero de ninguna manera digo 'nunca use granjas de prueba en la nube'. Tienen varias ventajas En primer lugar, esta no es solo una máquina virtual, sino una solución completa para probar la automatización con un conjunto de funciones listas para usar: acceso remoto, registros, capturas de pantalla, grabación de video, varios navegadores y dispositivos móviles físicos. En muchas situaciones, esta puede ser una alternativa elegante indispensable. Especialmente las plataformas de prueba son útiles para la automatización de iOS cuando las nubes públicas solo pueden ofrecer sistemas Linux / Windows. Pero hablar sobre iOS estará en futuros artículos. Recomiendo mirar siempre la situación y comenzar desde las tareas: en algunas es más barato y más eficiente usar nubes públicas, y en algunas plataformas de prueba definitivamente vale la pena el dinero gastado.

Ilustración del estado actual de la infraestructura.




Enlaces de aprendizaje



Herramientas similares:



6. Orquestación


Resumen de tecnología


Tengo buenas noticias: ¡casi hemos llegado al final del artículo! Por el momento, nuestra infraestructura de automatización consiste en pruebas web y de Android, que ejecutamos a través de GitLab CI en paralelo, utilizando herramientas con soporte Docker: Selenium grid y Selenoid. Además, utilizamos máquinas virtuales creadas a través de GCP para levantar contenedores con navegadores y emuladores en ellos. Para reducir costos, iniciamos estas máquinas virtuales solo bajo demanda y nos detenemos cuando no se realizan las pruebas. ¿Hay algo más que pueda mejorar nuestra infraestructura? ¡La respuesta es sí! ¡Conoce a Kubernetes (K8s)!

Para comenzar, considere cómo se relacionan las palabras orquestación, clúster y Kubernetes. En un nivel alto, la orquestación es un sistema que implementa y administra aplicaciones. Para automatizar las pruebas, estas aplicaciones en contenedores son Selenium grid y Selenoid. Docker y K8 se complementan entre sí. El primero se usa para implementar aplicaciones, el segundo para la orquestación. A su vez, K8s es un clúster. La tarea del clúster es usar máquinas virtuales como nodos, lo que le permite instalar varias funcionalidades, programas y servicios dentro de un servidor (clúster). Si alguno de los Nodos falla, entonces otros Nodos se recuperarán, lo que garantiza que nuestra aplicación funcione sin problemas. Además de esto, K8s tiene una funcionalidad importante relacionada con el escalado,gracias a lo cual obtenemos automáticamente la cantidad óptima de recursos, en función de la carga y las restricciones establecidas.

En verdad, la implementación manual de Kubernetes desde cero es una tarea completamente no trivial. Dejaré un enlace a Kubernetes The Hard Way, una guía práctica muy conocida, y si estás interesado, puedes practicar. Pero, afortunadamente, hay formas y herramientas alternativas. La más fácil de ellas es utilizar Google Kubernetes Engine (GKE) en GCP, que le permitirá obtener un clúster listo después de unos pocos clics. Para comenzar el estudio, le recomiendo que utilice este enfoque, ya que le permitirá enfocarse en aprender cómo usar K8 para sus tareas, en lugar de explorar cómo deben integrarse los componentes internos. 

Valor para la infraestructura de automatización.


Considere algunas de las características importantes que ofrece K8s:

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

Pero los K8 todavía no son una bala de plata. Para comprender todas las ventajas y limitaciones en el contexto de las herramientas que estamos considerando (Selenium grid, Selenoid), discutimos brevemente la estructura de los K8. El clúster contiene dos tipos de nodos: nodos maestros y nodos de trabajadores. Los nodos maestros son responsables de administrar, implementar y programar decisiones. Los nodos de los trabajadores es donde se ejecutan las aplicaciones. Los nodos también contienen un entorno de inicio de contenedor. En nuestro caso, este es Docker, que es responsable de las operaciones relacionadas con los contenedores. Pero hay soluciones alternativas como containerd. Es importante comprender que la escala o la autocuración no se aplica directamente a los contenedores. Esto se hace agregando / disminuyendo el número de pods, que a su vez contienen contenedores (generalmente un contenedor por pod, pero puede haber más dependiendo de la tarea). La jerarquía de alto nivel son los nodos de trabajo, dentro de los cuales hay pods, dentro de los cuales se levantan los contenedores.

La función de escala es clave y se puede aplicar tanto a los nodos dentro de un grupo de nodos del clúster como a los pods dentro de un nodo. Hay 2 tipos de escalado que se aplican tanto a los nodos como a las vainas. El primer tipo - horizontal - escalamiento ocurre debido a un aumento en el número de nodos / pods. Este tipo es más preferido. El segundo tipo, respectivamente, es vertical. El escalado se realiza aumentando el tamaño de los nodos / pods, no su número.

Ahora considere nuestras herramientas en el contexto de los términos anteriores.

Rejilla de selenio

Como se mencionó anteriormente, la cuadrícula de selenio es una herramienta muy popular, y no es de extrañar que estuviera en contenedores. Por lo tanto, no es sorprendente que la cuadrícula de selenio se pueda implementar en K8. Puede encontrar un ejemplo de cómo hacerlo en el repositorio oficial de K8. Como de costumbre, adjunto enlaces al final de la sección. Además de esto, la guía práctica muestra cómo hacer esto en la serie Terraform. También hay una instrucción sobre cómo escalar el número de pods que contienen contenedores con navegadores. Pero la función de autoescalado en el contexto de los K8 todavía no es una tarea obvia. Cuando comencé el estudio, no encontré ninguna guía práctica o recomendaciones.Después de varios estudios y experimentos con el apoyo del equipo de DevOps, elegimos el enfoque de generar contenedores con los navegadores deseados dentro de un pod, que se encuentra dentro de un nodo de trabajo. Este método nos permite aplicar la estrategia de escala horizontal de nodos al aumentar su número. Espero que en el futuro la situación cambie, y veremos más y más descripciones de los mejores enfoques y soluciones llave en mano, especialmente después del lanzamiento de Selenium grid 4 con una arquitectura interna modificada.especialmente después del lanzamiento de Selenium grid 4 con una arquitectura interna rediseñada.especialmente después del lanzamiento de Selenium grid 4 con una arquitectura interna rediseñada.

Selenoid :

Actualmente, implementar Selenoid en K8s es la mayor decepción. No son compatibles Teóricamente, podemos levantar un contenedor de Selenoid dentro de una cápsula, pero cuando Selenoid comienza a lanzar contenedores con navegadores, todavía estarán dentro de la misma cápsula. Esto hace que el escalado sea imposible y, como resultado, el trabajo de Selenoid dentro del clúster no será diferente del trabajo dentro de la máquina virtual. El fin de la historia.

Moon :

conociendo este cuello de botella mientras trabajaba con Selenoid, los desarrolladores lanzaron una herramienta más poderosa llamada Moon. Esta herramienta fue concebida originalmente para trabajar con Kubernetes y, como resultado, puede y debe usar la función de autoescala. Además, diría que por el momento es el únicouna herramienta en el mundo de Selenium, que de fábrica tiene soporte de clúster K8 nativo ( ya no está disponible, vea la siguiente herramienta ). Una característica clave de Moon que proporciona este soporte es: 
Completamente apátrida. Selenoid almacena en la memoria información sobre las sesiones de navegador que se ejecutan actualmente Si por alguna razón su proceso falla, entonces se pierden todas las sesiones en ejecución. Contrariamente, Moon no tiene un estado interno y puede replicarse en los centros de datos. Las sesiones del navegador permanecen activas incluso si una o más réplicas caen.
Entonces, Moon es una gran solución, pero con un problema, no es gratis. El precio depende del número de sesiones. Solo se pueden iniciar de 0 a 4 sesiones de forma gratuita, lo que no es particularmente útil. Pero, a partir de la quinta sesión, tendrá que pagar $ 5 por cada una. La situación puede diferir de una compañía a otra, pero en nuestro caso, usar Moon no tiene sentido. Como describí anteriormente, podemos iniciar máquinas virtuales con Selenium Grid a pedido o aumentar el número de nodos en el clúster. Para aproximadamente una tubería, lanzamos 500 navegadores y detenemos todos los recursos una vez que se completan las pruebas. Si usásemos Moon, tendríamos que pagar 500 x 5 adicionales = $ 2500 por mes y no importa la frecuencia con la que realicemos las pruebas. Y de nuevo, no digo "no use Moon". Para sus tareas, esta puede ser una solución indispensable, por ejemplo,si tiene muchos proyectos / equipos en su organización y necesita un gran grupo común para todos. Como siempre, dejo un enlace al final y recomiendo hacer todos los cálculos necesarios en el contexto de su tarea.

Callisto : ( ¡Atención! Esto no está en el artículo original y está contenido solo en la traducción al ruso )

Como dije, Selenium es una herramienta muy popular, y la industria de TI se está desarrollando muy rápidamente. Mientras trabajaba en la traducción, apareció una nueva herramienta prometedora de Callisto en la red (hola Cypress y otros asesinos de selenio). Funciona de forma nativa con K8 y le permite ejecutar contenedores selenoides en pods, distribuidos por nodos. Todo funciona desde el primer momento, incluido el autoescalado. Ficción, pero es necesario probar. Ya he logrado implementar esta herramienta y realizar algunos experimentos. Pero es demasiado pronto para sacar conclusiones, después de recibir los resultados a una gran distancia, quizás lo revise en los siguientes artículos. Hasta ahora solo dejo enlaces para investigación independiente.  







7. (IaC)



Y así llegamos a la última sección. Por lo general, esta tecnología y las tareas relacionadas no se incluyen en el área de responsabilidad de los ingenieros de automatización. Y hay razones para esto. En primer lugar, en muchas organizaciones, los problemas de infraestructura están bajo el control del departamento de DevOps y los equipos de desarrollo no se preocupan realmente de con qué trabaja la tubería y cómo apoyar todo lo relacionado con ella. En segundo lugar, seamos honestos, la práctica de "Infraestructura como código (IaC)" todavía no se aplica en muchas empresas. Pero definitivamente se ha convertido en una tendencia popular, y es importante tratar de involucrarse en procesos, enfoques y herramientas relacionados. O al menos mantenerse al tanto de los desarrollos.

Comencemos con la motivación para usar este enfoque. Ya hemos discutido que para ejecutar las pruebas en GitlabCI necesitamos al menos los recursos para ejecutar el Gitlab Runner. Y para ejecutar contenedores con navegadores / emuladores, necesitamos reservar una VM o clúster. Además de probar recursos, necesitamos un número significativo de capacidades para soportar entornos de desarrollo, etapas, producción, que también incluye bases de datos, programaciones automáticas, configuraciones de red, equilibradores de carga, derechos de usuario, etc. Una cuestión clave es el esfuerzo requerido para apoyar todo esto. Hay varias formas en que podemos hacer cambios y lanzar actualizaciones. Por ejemplo, en el contexto de GCP, podemos usar la consola de la interfaz de usuario en el navegador y realizar todas las acciones haciendo clic en los botones.Una forma alternativa sería usar llamadas API para interactuar con entidades en la nube o usar la utilidad de línea de comandos gcloud para realizar las manipulaciones necesarias. Pero con un gran número de entidades y elementos de infraestructura diferentes, se hace difícil o incluso imposible realizar todas las operaciones manualmente. Además, todas estas acciones manuales son incontrolables. No podemos enviarlos para su revisión antes de la ejecución, usar el sistema de control de versiones y retroceder rápidamente las ediciones que llevaron al incidente. Para resolver tales problemas, los ingenieros crearon y están creando scripts de bash / shell automáticos, que no es mucho mejor que los métodos anteriores, ya que no son tan fáciles de leer, comprender, mantener y modificar en un estilo de procedimiento.

En este artículo y procedimientos, utilizo 2 herramientas relacionadas con la práctica de IaC. Estos son Terraform y Ansible. Algunos creen que no tiene sentido usarlos simultáneamente, ya que su funcionalidad es similar y son intercambiables. Pero el hecho es que inicialmente se enfrentan a tareas completamente diferentes. Y el hecho de que estas herramientas deberían complementarse entre sí se confirmó en una presentación conjunta de los desarrolladores que representan a HashiCorp y RedHat. La diferencia conceptual es que Terraform es una herramienta de aprovisionamiento para administrar los propios servidores. Mientras que Ansible es una herramienta de administración de configuración cuya tarea es instalar, configurar y administrar software en estos servidores.

Otra característica distintiva clave de estas herramientas es el estilo de escritura de código. A diferencia de bash y Ansible, Terraform utiliza un estilo declarativo basado en la descripción del estado final deseado, que debe lograrse como resultado de la ejecución. Por ejemplo, si vamos a crear 10 máquinas virtuales y aplicar los cambios a través de Terraform, obtendremos 10 máquinas virtuales. Si vuelve a aplicar el script, no pasará nada, ya que tenemos 10 máquinas virtuales y Terraform lo sabe, porque almacena el estado actual de la infraestructura en un archivo de estado. Pero Ansible utiliza un enfoque de procedimiento y, si le pide que cree 10 máquinas virtuales, en la primera ejecución obtenemos 10 máquinas virtuales, de manera similar con Terraform. Pero después de reiniciar, ya tendremos 20 máquinas virtuales. Esta es una diferencia importante.En estilo de procedimiento, no almacenamos el estado actual y simplemente describimos la secuencia de pasos que deben completarse. Por supuesto, podemos manejar diversas situaciones, agregar varias comprobaciones de la existencia de recursos y el estado actual, pero no tiene sentido perder el tiempo y hacer esfuerzos para controlar esta lógica. Además, esto aumenta el riesgo de cometer errores. 

Resumiendo todo lo anterior, podemos concluir que para el aprovisionamiento de servidores, Terraform y la notación declarativa son una herramienta más adecuada. Pero el trabajo de gestión de la configuración se delega mejor a Ansible. Habiendo tratado con esto, veamos ejemplos de uso en el contexto de la automatización.

Valor para la infraestructura de automatización.


Es importante comprender solo que la infraestructura de automatización de pruebas debe considerarse como parte de toda la infraestructura de la empresa. Esto significa que todas las prácticas de IaC deben aplicarse globalmente a los recursos de toda la organización. Quién es responsable de esto depende de sus procesos. El equipo de DevOps tiene más experiencia en estos asuntos, ven la imagen completa de lo que está sucediendo. Sin embargo, los ingenieros de control de calidad están más involucrados en el proceso de automatización de edificios y la estructura de la tubería, lo que les permite ver mejor todos los cambios requeridos y las oportunidades de mejora. La mejor opción es trabajar juntos, compartir conocimientos e ideas para lograr el resultado esperado. 

Estos son algunos ejemplos del uso de Terraform y Ansible en el contexto de la automatización de pruebas y las herramientas que discutimos antes:

1. Describa a través de Terraform las características y parámetros necesarios de máquinas virtuales y clústeres.

2. Instale con Ansible las herramientas necesarias para probar: docker, Selenoid, Selenium Grid y descargue las versiones necesarias de navegadores / emuladores.

3. Describa a través de Terraform las características de la VM en la que se ejecutará el GitLab Runner.

4. Instale con Ansible GitLab Runner y las herramientas relacionadas necesarias, establezca la configuración y las configuraciones.

Ilustración del estado actual de la infraestructura.



Enlaces de estudio:



Herramientas similares




¡Para resumir!


PasoTecnologíaHerramientasValor para la infraestructura de automatización.
1Local runningNode.js, Selenium, Appium
  • web mobile
  • ( Node.js)

2Version control systems Git

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

4CI / CDGitlab CI
  • /

5Cloud platformsGoogle Cloud Platform
  • ( )

6OrchestrationKubernetes/ pods:
  • /

7Infraestructura como código (IaC)Terraform, ansible
  • Beneficios similares con la infraestructura de desarrollo
  • Todos los beneficios de las versiones de código
  • Fácil de hacer cambios y mantener
  • Completamente automatizado



Diagramas de mapas mentales: evolución de la infraestructura


paso1: local


paso2: vcs


Paso 3: contenedorización 


Paso 4: CI / CD 


Paso 5: plataformas en la nube


paso 6: orquestación


Paso 7: IaC


¿Que sigue?


Así que este es el final del artículo. Pero en conclusión, me gustaría establecer algunos acuerdos con usted.

Por su parte
Como se dijo al principio, me gustaría que el artículo sea de uso práctico y lo ayude a aplicar los conocimientos adquiridos en el trabajo real. Agrego nuevamente un enlace a una guía práctica .

Pero incluso después de eso, no se detenga, practique, estudie los enlaces y libros relevantes, descubra cómo funciona en su empresa, encuentre lugares que se puedan mejorar y participe en ellos. Buena suerte

De mi parte

Del título está claro que esta fue solo la primera parte. A pesar de que resultó ser bastante grande, aquí todavía no se revelan temas importantes. En la segunda parte, planeo considerar la infraestructura de automatización en el contexto de IOS. Debido a las limitaciones de Apple con respecto a la ejecución de simulaciones de iOS solo en sistemas macOS, nuestro conjunto de soluciones se ha reducido. Por ejemplo, no podemos usar Docker para ejecutar un simulador o nubes públicas para ejecutar máquinas virtuales. Pero esto no significa que no haya otras alternativas. ¡Intentaré mantenerlo actualizado con soluciones avanzadas y herramientas modernas!

Además, no mencioné temas muy amplios relacionados con el monitoreo. En la Parte 3, voy a considerar las herramientas más populares para monitorear la infraestructura, así como qué datos y métricas considerar.

Y finalmente. En el futuro planeo lanzar un video curso sobre cómo construir una infraestructura de prueba y herramientas populares. Actualmente hay bastantes cursos y conferencias sobre DevOps en Internet, pero todos los materiales se presentan en el contexto del desarrollo, pero no de la automatización de pruebas. En este asunto, realmente necesito comentarios si este curso será interesante y valioso para la comunidad de probadores e ingenieros de automatización. ¡Gracias por adelantado!

More articles:


All Articles