Get best of the week

Código abierto: infraestructura de prueba de CI / CD y Avito para Android

Movimos Avito para la infraestructura de código abierto de Android: complementos de Gradle, emuladores y bibliotecas de prueba. Nuestro código será útil para automatizar CI / CD y también facilitará la escritura y el soporte de las pruebas automáticas.

En este artículo de revisión, explicaremos por qué decidimos hacer nuestro trabajo abierto, sobre las bibliotecas más importantes del proyecto y orientaremos hacia dónde ir con los problemas emergentes. Analizaremos en detalle las bibliotecas individuales, los complementos de Gradle y nuestros enfoques de desarrollo en los siguientes materiales.



Quiénes somos y qué hacemos


Estamos trabajando en la industria de Android en el equipo de la plataforma Speed. Hay cuatro de los nuestros:
Seryozha Boishtyan
Ingeniero sénior
Cuenta de Twitter


Dima Voronin
Ingeniero principal
cuenta de Twitter


Zhenya Krivobokov
Ingeniero sénior
Cuenta de Twitter


Daniil Popov
Ingeniero sénior
Cuenta de Twitter


Somos responsables de entregar los cambios en todas las aplicaciones Avito de Android a los usuarios más rápido. Nuestra área de responsabilidad incluye:

  • Trabajo local con el proyecto: para que todo se ensamble rápidamente y el IDE no se ralentice.
  • Canalización de CI: pruebas, todas las comprobaciones posibles.
  • CD: herramientas para ingenieros de lanzamiento.

¿Por qué necesitamos código abierto?


No solo queríamos reflejar el código en un repositorio abierto en Github, sino hacerlo en beneficio de nosotros mismos y de la comunidad de ingenieros. Las principales razones para llevar el proyecto a código abierto son cinco:

  • Obtenga comentarios
  • Influyendo en los estándares de la industria.
  • Aprender cosas nuevas.
  • Afecta a las bibliotecas de terceros.
  • Impulsa tu marca personal.

Vamos a repasarlos brevemente.

Obtenga comentarios y haga que el código sea más fácil de reutilizar


Realizamos ajustes para los ingenieros de Avito, y nuestros usuarios necesitan todas las soluciones para funcionar. Nos faltan las opiniones de los desarrolladores que resuelven problemas similares. Será genial si señalan problemas en la implementación interna y la conveniencia de conectarse a nuestro proyecto.

Ya hemos visto cómo portar código a Github resalta los problemas de reutilización. Cuando entiendes que otras compañías pueden usar esto, miras la arquitectura de manera diferente. Reutilizar el código no es un fin en sí mismo. Pero este criterio externo dice mucho sobre la calidad de la arquitectura y su flexibilidad.

Influyendo en los estándares de la industria


Desarrollamos infraestructura para aplicaciones móviles desde 2017 y hablamos regularmente de ella en conferencias y reuniones:


Además de las historias, siempre quisimos compartir el código y dar la oportunidad de reutilizarlo. De hecho, muchos desarrolladores de Android enfrentan desafíos similares:

  • Cómo escribir autotests para que se beneficien.
  • Cómo ejecutarlos en solicitudes de extracción.
  • Cómo más barato para mantener la infraestructura.

No existen soluciones generalmente aceptadas y establecidas para estas tareas: cada empresa opera a su manera. Compartimos nuestras mejores prácticas para que en los nuevos proyectos los desarrolladores no tengan que recopilar información bit a bit sobre la prueba de aplicaciones móviles y la creación de CI / CD. Me gustaría tener soluciones preparadas para problemas de rutina en lugar de escribir mi bicicleta. E, incluso si nadie usa el código del proyecto en su forma original, los desarrolladores podrán espiar nuestros enfoques y mejorar sus propias bibliotecas.

Aprende explicando a los demás


Simplemente poner el código en código abierto no es suficiente. Las prácticas, enfoques, formas de encontrar problemas y tomar decisiones son importantes. Al mostrarlos, verificamos cómo funcionan nuestras ideas y propuestas listas fuera de Avito.

Afecta las bibliotecas de terceros y soluciona sus problemas más rápido


Imagine que tiene un problema en un Android o biblioteca y no puede encontrar una solución. Necesita ayuda de la comunidad o los autores del código. Hiciste una pregunta sobre Stack Overflow, creaste un error en Google IssueTracker, describiste todo en detalle, pero el problema no se reproduce. Se le solicita un caso de prueba. Todo esto lleva tiempo extra.

El código abierto te ayuda a crear un ejemplo reproducible más rápido. Tenemos una aplicación de prueba que utiliza parte de la infraestructura. Su tarea principal es alimentar a los perros, es decir, verificar lo antes posible con un ejemplo simple y aislado que todo funciona. Pero esta misma aplicación hace que sea más fácil mostrar errores. Cuando damos un ejemplo reproducible en una biblioteca extranjera, su autor es más fácil de entender cuál es el problema. Esto aumenta las posibilidades de que emprenda mejoras.

La popularidad de un proyecto de código abierto también aumenta la probabilidad de que le presten atención. Señalar un problema en una biblioteca con un montón de estrellas y usuarios aumenta la presión, es más difícil de ignorar. Obtener ese resultado sin código abierto es más difícil: su aplicación debe ser muy popular o debe conocerla personalmente.

Relaciones públicas y motivación personal


Por último, pero no menos importante, es el beneficio personal. Todos se benefician de la publicidad del trabajo diario. La compañía atrae la atención debido a un producto útil, y bombeamos una marca personal como ingenieros y obtenemos motivación adicional para el trabajo. Ya no necesita buscar tiempo por las tardes para sus propios proyectos o compromisos en bibliotecas de código abierto de terceros.

Lo que fue llevado a código abierto


Ponemos casi toda nuestra infraestructura de prueba de Android y CI / CD en el repositorio de Github . Para facilitar que otros desarrolladores naveguen por el proyecto, todos los módulos están agrupados por propósito:




Notaré un par de las bibliotecas más importantes.

Corredor de prueba


Este es un complemento de gradle para ejecutar pruebas de instrumentación. El análogo más cercano es Marathon , pero el nuestro está escrito solo para Android.

Corredor de prueba:

  • Describe qué pruebas ejecutar. Hay filtros por anotaciones, por paquetes, por los resultados del último lanzamiento.
  • Describe en qué emuladores ejecutar pruebas. Los respalda a Kubernetes o se conecta a emuladores locales.
  • Establece las condiciones para reiniciar las pruebas.
  • Envía un informe final con los resultados de la ejecución de la prueba.

Los resultados se almacenan en TMS personalizado (sistema de gestión de pruebas), no está en código abierto. Estamos trabajando en la posibilidad de conectar otra implementación.



Análisis de impacto


Tenemos alrededor de 1600 pruebas de instrumentación y pruebas de unidad de 10K. Nos gustaría ejecutar todas las pruebas para cualquier cambio de código, pero esto no es posible: la ejecución llevará demasiado tiempo.

Una solución simple es dividir manualmente las pruebas en diferentes conjuntos, por ejemplo, pruebas de humo, rápido, lento y ejecutar solo una parte. Pero con este enfoque, siempre existe la posibilidad de perder un error, porque no está claro qué conjunto de pruebas es óptimo. La solución ideal es comprender qué conjunto mínimo de pruebas verificará todos los cambios. Esto se llama análisis de impacto de prueba .

Escribimos un complemento de Gradle que busca cambios en los módulos, analiza las pruebas y determina cuáles ejecutar.



Los módulos y enfoques principales se describen con más detalle en la documentación del proyecto .
Ahora ella no es muy buena, e incluso no todo está traducido. Queremos que la documentación sea más fácil de entender, y necesitamos su ayuda. Díganos qué finalizar y corregir en el texto en nuestro chat de telegramas .



Cómo nuestras bibliotecas pueden ser útiles


Dado que el proyecto tiene muchos componentes, su uso depende de sus necesidades. Si está resolviendo un problema similar o simplemente quiere comprender la tecnología, no dude en escribirnos en un chat de telegramas en ruso o en inglés . Le diremos lo que sabemos, trataremos de ayudarlo y le mostraremos ejemplos relevantes.

Puedes preguntar lo que sea:

  • ¿Cómo trabajas con pruebas inestables?
  • ¿Por qué tanto código? El es inútil.
  • ¿Por qué todo el código está en los complementos de Gradle, no en los scripts de Python?

Si desea utilizar un módulo específico, puede probarlo en una aplicación de prueba . Ahora muestra un ejemplo de uso de test runner.

Desafortunadamente, todavía tenemos pocos ejemplos de reutilización en otros proyectos, por lo que la integración aún puede revelar restricciones desconocidas. Escríbanos si esto sucede, y veremos qué necesita ser finalizado.

Conclusión


En los siguientes artículos planeamos hablar sobre:

  • Nuestro corredor de pruebas.
  • Anatomía de la prueba: qué sucede al presionar el botón "Ejecutar" en el IDE para obtener el resultado.
  • Cómo luchamos con la inestabilidad de las pruebas y la infraestructura.
  • Nuestros enfoques para la infraestructura de escritura.
  • Cómo redujimos el tiempo de lanzamiento de mes a semana.

Hay ideas sobre temas más generales:

  • Cómo comenzar a escribir exámenes.
  • Fundamentos de las pruebas para principiantes: acerca de enfoques y tecnologías comunes.

Cuéntanos en los comentarios lo que te interesará saber. Entonces entenderemos qué texto escribir primero.

More articles:


All Articles