Como desarrollador de Android, casi siempre tienes acceso a uno Dispositivos. Sin embargo, cuando se trata de hardware, el dispositivo que realmente necesita a menudo ya está en uso, configurado incorrectamente, almacenado en otro laboratorio o simplemente esperando a ser reiniciado. Fue entonces cuando los costos de desarrollo de Android comenzaron a aumentar.
porque no lo es solo El equipo en sí genera costos, al igual que todo lo que lo rodea: adquisición, configuración, mantenimiento, acceso remoto, capacidad del laboratorio y, lo peor de todo: su tiempo de ingeniería. Todavía hay un costo para los desarrolladores que esperan el entorno de desarrollo adecuado.
Entonces, ¿cómo solucionar este problema?
¿Realmente necesito hardware para mis pruebas?
Todos sabemos que el hardware sigue desempeñando un papel importante en el desarrollo de Android. Si necesita verificar sensores, periféricos, el rendimiento real del objetivo, la integración del hardware en sí o incluso la experiencia real del usuario, necesitará dispositivos de destino físicos.
Pero la mayoría de las cargas de trabajo que compiten con estos dispositivos pueden ejecutarse en otros lugares.
Al crear Android, probar aplicaciones, Reproducir el errore incluso realizar pruebas de regresión, sin necesidad de ningún equipo físico. Por lo tanto, debería preguntarse si se necesita un determinado dispositivo en lugar de si un dispositivo de destino específico está disponible.
Esta distinción es importante aquí porque los laboratorios de hardware son obviamente más difíciles de escalar que los laboratorios de software.
Más desarrolladores normalmente significa más compilaciones, más pruebas y más configuraciones. Esto a menudo significa una mayor demanda de equipos, bancos de trabajo y más infraestructura para proporcionar capacidad suficiente para las horas pico cuando se depende de la prioridad del hardware. Como puede ver, los costos de desarrollo de Android no son solo el resultado del dispositivo en sí, sino también del esfuerzo que implica ejecutar el dispositivo y el tiempo de ingeniería perdido cuando el acceso se convierte en un cuello de botella.
Operaciones de infraestructura de Android
Cuando las cargas de trabajo se trasladan del hardware, el entorno de Android se puede aprovisionar cuando sea necesario, integrarse en canales de integración continua y entrega/implementación continua (CI/CD), ejecutarse en paralelo y luego descartarse. Un enfoque centrado en la nube es mucho más sencillo que un enfoque de hardware. Simplemente solicite su entorno, ejecute las pruebas y publíquelo de forma segura.
El truco secreto es ser prudente al elegir el entorno de ejecución adecuado para el trabajo que desea ejecutar: use contenedores cuando se requiera densidad y escala de aplicaciones, máquinas virtuales si necesita ejecutar imágenes personalizadas de Android y dispositivos físicos cuando sus pruebas realmente dependan de componentes físicos.
Con Anbox Cloud, estos entornos de nube pueden coexistir exactamente en el mismo flujo de trabajo de desarrollo. Los desarrolladores pueden seguir utilizando herramientas conocidas como Android Debug Bridge (ADB), Android Studio, marcos de prueba existentes y sistemas CI/CD populares.
Tomemos como ejemplo un equipo de soporte o verificación que necesita reproducir un problema en muchas configuraciones de Android. En una configuración de hardware primero, esto significa encontrar el dispositivo correcto, verificar su versión de software, conservarlo, reconfigurarlo y configurar el acceso remoto antes de que comience la depuración.
Con un entorno Android basado en la nube, el mismo equipo puede mantener imágenes predefinidas de configuraciones comunes y ejecutarlas a pedido. Varios ingenieros pueden trabajar en paralelo, mientras que el dispositivo físico se reserva para situaciones en las que realmente se requiere la verificación del hardware.
En este caso, la reducción de costes va más allá de tener un teléfono menos en el lineal. Se refiere al tiempo que lleva encontrar, preparar y compartir un teléfono, así como a la capacidad adicional necesaria para garantizar que el teléfono esté disponible durante los picos de demanda. El equipo inactivo es ineficiente. El costo de los ingenieros que se quedan inactivos porque no tienen el equipo adecuado es aún mayor.
¿De dónde provienen los costos de desarrollo de Android y cómo reducirlos?
En términos generales, hay tres áreas de costos en las que vale la pena centrarse: el primer costo obvio es el hardware, luego las operaciones (configuración, mantenimiento, etc.) y, por último, pero no menos importante: el tiempo de ingeniería. El impacto de este último factor puede subestimarse fácilmente.
Si menos cargas de trabajo dependen de equipos especializados, los equipos necesitarán menos capacidad de hardware para soportar el mismo nivel de actividad de desarrollo. Así es como el uso de Anbox Cloud puede ayudarlo a mejorar estas tres áreas de costos:
- Costos de hardware: se requieren menos dispositivos, estaciones de trabajo e infraestructura de soporte para los picos de demanda
- Costos operativos: Reduzca la configuración manual, el mantenimiento y la gestión ambiental.
- Costo del tiempo de ingeniería: menos espera en recursos compartidos y más oportunidades para ejecutar cargas de trabajo en paralelo
Si es necesario ejecutar diez pruebas, no necesariamente tienen que estar en cola detrás del mismo banco de trabajo físico. Si es necesario reproducir un problema, los ingenieros no tienen que dedicar tiempo a reconstruir manualmente la configuración correcta. Los entornos definidos por software se pueden crear específicamente para cargas de trabajo y luego eliminarlos.
Esto también significa que puede conservar el hardware personalizado que tenga para realizar pruebas que serían imposibles sin él. Por lo tanto, reducir los costos de desarrollo de Android implica más que simplemente reducir los gastos de hardware. Se convirtió en una forma de sacar más trabajo de ingeniería de la infraestructura y recuperar el tiempo de ingeniería ya existente.
Saque el hardware del camino crítico
Como me gustaría decir, el punto aquí no es deshacerse por completo de los dispositivos físicos. El objetivo es garantizar que el hardware costoso sólo se utilice porque la prueba lo requiere, no porque el flujo de trabajo se base en él.
Esto significa ejecutar cargas de trabajo basadas en software con anticipación, ejecutar más cargas de trabajo en paralelo y reservar esos bancos de trabajo físicos para trabajos de validación o certificación para brindar valor real.
No escale el desarrollo de Android agregando dispositivos constantemente, sino escale el entorno alrededor de los dispositivos. Menos esperas, más escalamiento e iteración más rápida.
Deja de seguir el dispositivo. Ejecute Android en la nube.
Android es una marca comercial de Google LLC.
Anbox Cloud utiliza recursos proporcionados a través del Proyecto de código abierto de Android.
Android Robot se copia o modifica de trabajos creados y compartidos por Google y tiene la licencia intercambio de conocimientos Licencia de Atribución 3.0.
