Cómo un entorno Android bajo demanda convierte la validación en una etapa de canalización repetible
En el primer artículo, analizamos la automatización: cómo crear y administrar mediante programación entornos Android. En la segunda pregunta, analizamos el escalamiento: cómo la infraestructura compartida puede hacer que estos entornos estén disponibles para más desarrolladores, pruebas y cargas de trabajo.
El tercer artículo se centra en el siguiente paso: integrar estos entornos directamente en CI/CD.
Un sistema CI/CD ya puede automatizar gran parte del proceso de entrega de software, desde la creación de una aplicación o una imagen de Android hasta la activación de pruebas y la presentación de informes de resultados. Sin embargo, el entorno de ejecución de Android aún puede existir fuera de este flujo de trabajo. Considere la siguiente desconexión:
- La aplicación se puede crear automáticamente, pero alguien debe conectarse al dispositivo para iniciar la verificación.
- La solicitud de extracción llega a la etapa manual porque el entorno de Android requerido no está disponible en proceso.
- La prueba pasa en una estación de trabajo pero falla en otra porque el entorno subyacente ha cambiado.
Este es el vacío que llena la integración CI/CD. Con Anbox Cloud, el entorno de ejecución de Android se convierte en otro recurso que la canalización puede solicitar cuando sea necesario. Los flujos de trabajo pueden solicitar los entornos necesarios, implementar artefactos, iniciar la validación, recopilar resultados y liberar recursos cuando se completen las tareas.
En lugar de tratar a Android como un componente separado del proceso, este entorno lo integra en el proceso automatizado de entrega de software.
En este artículo, «entorno de ejecución de Android» se refiere a la instancia de Android en la que se ejecuta y verifica la aplicación o el sistema, incluida la imagen de Android, la configuración, los recursos asignados y la configuración de prueba.
Haga de Android parte de su flujo de trabajo
Los canales de CI/CD se basan en la repetibilidad. Los cambios producen artefactos, las pruebas se realizan con entradas definidas y la canalización registra suficiente información para comprender los resultados.
El entorno de ejecución es parte del proceso. Las canalizaciones de CI/CD ya proporcionan recursos temporales como contenedores, máquinas virtuales, repositorios y servicios como parte del trabajo. A través de Anbox Cloud, el entorno de ejecución de Android puede convertirse en otro recurso solicitado por la canalización cuando sea necesario.
La canalización no considera un dispositivo físico o un emulador nativo como requisito previo, sino que solicita un entorno de Android con una imagen y configuración conocidas. Implementa el artefacto, realiza la verificación requerida, recopila pruebas y libera recursos.
Anbox Cloud no crea aplicaciones o plataformas de Android. Esto sigue siendo responsabilidad del sistema constructivo existente. Su función es proporcionar el entorno Android necesario para la verificación a través de un ciclo de vida programable y repetible.
Canalización típica de Android
Las herramientas exactas varían, pero el flujo de trabajo es generalmente consistente. La canalización primero produce o recupera artefactos para su verificación. Para el equipo de aplicaciones, esto podría ser un APK. Para los equipos de plataforma, podría ser una imagen completa del sistema operativo Android o Android Automotive.
Normalmente, después de solicitar un entorno predefinido, el proceso puede implementar artefactos, preparar materiales de prueba y establecer conexiones (por ejemplo, utilizando ADB). Una vez hecho esto, se recopilan informes de prueba, registros, capturas de pantalla, datos de fallos y métricas de rendimiento antes de eliminar el entorno.
Cada etapa del proceso debe ser clara. La canalización debe saber qué artefacto se probó, qué entorno de Android se utilizó, qué configuración se aplicó y qué resultado se produjo.
Sin este contexto, la automatización puede acelerar las pruebas pero no mejorará la confiabilidad de los resultados.
La repetibilidad es más importante que la automatización
Poder iniciar Android automáticamente es útil, pero iniciar el mismo entorno de manera constante es aún más valioso.
Es difícil confiar en los resultados cuando las versiones de Android cambian entre ejecuciones, las configuraciones se cambian manualmente, los datos almacenados en caché afectan los resultados o las aplicaciones más antiguas aún están instaladas. Hacer explícitas estas entradas en su flujo de trabajo de CI/CD puede reducir los errores de configuración manual y mejorar la repetibilidad.
Las imágenes de Android, los artefactos de la aplicación, los recursos de la instancia, la configuración de visualización, las entradas de prueba y los resultados esperados se pueden asociar con una ejecución específica. Los flujos de trabajo también pueden esperar a estados conocidos en lugar de depender de retrasos arbitrarios o suposiciones sobre cuándo estará listo el entorno.
El script dice: «Inicie Android y ejecute esta prueba». Una canalización reproducible dice: «En este entorno definido, ejecute esta versión de la prueba contra este artefacto utilizando estas entradas, conservando evidencia suficiente para interpretar los resultados».
Cuando un problema técnico impide un lanzamiento, los equipos necesitan un segundo modelo.
Preservar evidencia, no infraestructura innecesaria
Los entornos desechables permiten que cada ejecución comience desde un estado limpio, pero eliminar el entorno no significa perder la información necesaria para la depuración.
Cuando la validación falla, la canalización debe recopilar información de diagnóstico relevante antes de liberar el recurso. También puede registrar definiciones ambientales para que los ingenieros puedan restablecer las mismas condiciones más adelante. En algunos casos, puede resultar útil reservar temporalmente una instancia para la investigación interactiva.
El objetivo no es retener indefinidamente todos los entornos fallidos. Un principio mejor sería presuponer la preservación de la evidencia y proteger el medio ambiente cuando agregue valor.
Esto mantiene la eficiencia de los flujos de trabajo y, al mismo tiempo, proporciona a los equipos suficiente información para comprender y reproducir las fallas.
Un modelo operativo para diferentes cargas de trabajo de Android
Los equipos de aplicaciones y plataformas validan diferentes artefactos, pero el modelo operativo sigue siendo el mismo.
La canalización de la aplicación puede instalar el APK y realizar pruebas de instrumentación, UI, compatibilidad o integración. La canalización de la plataforma puede verificar imágenes completas del sistema Android, configuraciones del sistema operativo Android Auto, servicios de plataforma o compilaciones OEM personalizadas.
El entorno de ejecución también puede diferir. Las cargas de trabajo orientadas a aplicaciones pueden beneficiarse de Android en contenedores cuando la densidad y el tiempo de arranque son importantes. Las cargas de trabajo completas del sistema pueden requerir Android virtualizado con límites completos de máquinas virtuales.
Éstas son opciones de implementación. La historia del proceso sigue siendo consistente: los cambios producen artefactos, el flujo de trabajo solicita el entorno Android apropiado y la verificación puede comenzar sin esperar a que alguien prepare el hardware.
Mantenga a las personas y al hardware donde agregan valor
No todas las decisiones de validación se pueden automatizar. Es posible que los desarrolladores deban comprobar si hay problemas gráficos, los ingenieros de control de calidad pueden necesitar comprobar si hay diferencias visuales y los ingenieros de plataformas pueden necesitar investigar de forma interactiva el comportamiento del sistema. El entorno aún se puede recrear, transmitir o compartir temporalmente para el trabajo.
El hardware físico sigue siendo fundamental para verificar sensores, periféricos, radios, controladores, consumo de energía, comportamiento térmico y rendimiento de producción final. Pero no es necesario que cargue con toda la carga del proceso de desarrollo. El entorno programable puede proporcionar retroalimentación temprana y una verificación paralela más extensa antes de que el software llegue a la etapa final de hardware.
Una estrategia equilibrada es ejecutar cada cambio, validarlo exhaustivamente en la nube y, finalmente, certificarlo en el hardware de destino.
Android ya no debería ser una excepción manual
La automatización hace que el entorno de Android sea programable. Las capacidades de expansión pueden proporcionar esta capacidad cuando su flujo de trabajo lo requiera. CI/CD aporta ambas capacidades al proceso de entrega de software, donde la retroalimentación es más valiosa.
La canalización puede solicitar entornos, implementar artefactos, ejecutar validaciones, recopilar pruebas y liberar recursos sin tener que esperar a que alguien conecte un dispositivo o prepare una máquina de prueba.
Android se convierte en parte del flujo de trabajo en lugar de una dependencia externa del mismo. El hardware físico sigue siendo la prueba definitiva, pero los comentarios periódicos de Android ya no tienen que esperar.
Este es el cambio más amplio que explora esta serie: la transformación de Android de un activo físico escaso a una infraestructura de ingeniería programable.
lectura adicional
Lea la Parte 1: El desarrollo de Android no debería comenzar con un dispositivo físico
Lea la Parte 2: Ampliar el desarrollo de Android sin escalar el hardware
Si tiene alguna pregunta, no dude en Ponte en contacto con el equipo de Anbox.
