1. Introducción a DevOps para Frontend
Hoy hablaremos sobre DevOps para frontend más allá de los navegadores de escritorio. Definiremos qué significa más allá de los navegadores de escritorio, especialmente en el contexto de DaZone. Abordaremos el viaje hacia DevOps y exploraremos las características que se pueden tomar prestadas de DevOps en el backend para el frontend. DaZone ofrece transmisión en vivo de deportes en más de 200 países en varios dispositivos basados en HTML y JavaScript. Nuestro flujo de trabajo involucra equipos de funciones, equipos de dispositivos y finalmente clientes. Un desafío es el bajo ciclo de retroalimentación debido a la participación de múltiples equipos.
Hola a todos, y gracias por acompañarme. Hoy hablaremos sobre DevOps para frontend más allá de los navegadores de escritorio. Mi nombre es Max Gallo. Soy un ingeniero principal de Londres. Trabajo en DaZone. Puedes encontrarme en Twitter como underscore Max Gallo. El tema de hoy es bastante grande, y quiero dividirlo en tres partes diferentes.
Al principio, estableceremos el contexto. Definiremos qué significa más allá de los navegadores de escritorio, especialmente en el contexto de DaZone, en el contexto de transmisión en vivo de deportes. Después de eso, abordaremos el viaje hacia DevOps. ¿Cómo llegamos a DevOps tal como lo conocemos hoy? ¿Y cuáles son las características que podemos robar, que podemos tomar prestadas del DevOps en el backend para el frontend? Y al final, veremos cómo se aplican esas características, si es que se aplican, para el frontend.
Pero comencemos más allá de los navegadores de escritorio. DaZone es una empresa de transmisión en vivo de deportes. Por lo tanto, ofrecemos deportes en vivo en todo el mundo en muchos dispositivos y en muchos países, más de 200 países. Entre todos estos dispositivos a los que apuntamos, hay casi 25 de ellos que son basados en HTML y JavaScript. Esto significa que estamos ejecutando nuestra aplicación web en algún tipo de navegador que está integrado en el dispositivo. Pero, ¿de qué dispositivos estamos hablando? Principalmente estoy hablando de tus televisores que tienes en tu sala de estar y tu consola de juegos, tu último y brillante PS5 o Xbox, o tal vez un conjunto de cajas que viene con tu proveedor de red y posiblemente más. Actualmente, estamos admitiendo más de 25 de ellos. Entonces, con todas estas ideas y todos estos dispositivos, creamos nuestro flujo de trabajo de la siguiente manera. Comenzamos con equipos de funciones. Este es nuestro flujo de trabajo hasta hace seis meses, un año. Nuestros equipos de funciones trabajaban en características comunes. Todas las características comunes que se compartían en varios dispositivos comenzaban aquí. Teníamos varios equipos de funciones y una vez que terminaban, entregaban el código a los equipos de dispositivos. El objetivo de este equipo era asegurarse de que la aplicación funcionara correctamente en el propio dispositivo. Y una vez que los dispositivos estaban satisfechos, finalmente podíamos llegar a los clientes. La idea es función, luego dispositivos y luego cliente. Pero esta configuración en particular tiene sus propios desafíos. Y quiero comenzar con el primer desafío, que es un ciclo de retroalimentación bajo. ¿Por qué es bajo el ciclo de retroalimentación? Principalmente porque tenemos dos equipos diferentes que son necesarios para ir de un lugar a otro.
2. Desafíos y el Viaje hacia DevOps
Los equipos que constantemente se comunican entre sí pueden ralentizar las cosas. La visibilidad del trabajo es un desafío con múltiples equipos de funciones y equipos de dispositivos. Los equipos de dispositivos enfrentan problemas con la propiedad compartida. Los desafíos son el ciclo de retroalimentación lento, la visibilidad del trabajo poco clara y la propiedad compartida. El viaje hacia DevOps comienza enfatizando el rendimiento de todo el sistema. Los equipos de desarrollo y operaciones tienen similitudes. La pregunta es cómo llegamos al DevOps de hoy. Las abstracciones son factores contribuyentes poderosos.
Imagínate cualquier error o cualquier característica que pasa de un equipo a otro. Si encuentras algún problema, tiene que regresar, y esto continúa una y otra vez. Básicamente, estos dos equipos están constantemente hablando entre sí. Esto puede ralentizar las cosas.
El segundo desafío es la visibilidad del trabajo. Imagina el mejor escenario posible. Tienes un tablero Jira para los equipos de funciones y otro tablero Jira, digamos, para los equipos de dispositivos. Pero también tenemos múltiples equipos de funciones. De hecho, están divididos por dominios. Entonces, diferentes equipos de dominio trabajan en todas las características de ese dominio, lo que significa que tenemos varios tableros Jira aquí y también algunos tableros Jira aquí. Por lo tanto, responder a la pregunta de cuándo se lanzará esta característica no es tan fácil. Porque tienes que armar un rompecabezas con todas estas piezas dispersas en varios lugares. El tercer desafío es que los equipos de dispositivos no pueden solucionar los problemas correctamente. ¿Por qué? Porque no son dueños de la característica. En cierto sentido, si un equipo de funciones es dueño de su base de código con esa característica, luego entregan esa característica al equipo de dispositivos para asegurarse de que funcione en el Firestick, por ejemplo, en el Amazon Firestick, y el equipo de dispositivos dice que no funciona bien, intentaron solucionar algo, pero hay un error. Y esto significa que no son dueños de esa característica, tienen que volver al equipo de funciones. Por lo tanto, la propiedad para el equipo de dispositivos es realmente un problema. Quiero resumir los desafíos antes de continuar. En primer lugar, el ciclo de retroalimentación lento, este ping pong de errores y características entre estos dos equipos, uno está probando en dispositivos, el otro está trabajando en una característica más genérica. Pero también tenemos la visibilidad del trabajo, que no es muy clara cuándo se lanzará una característica o al menos no es tan sencillo como nos gustaría que fuera. Y luego hablamos de la propiedad del equipo de dispositivos, porque esta propiedad compartida entre la característica y los dispositivos no funciona muy bien, porque es una propiedad compartida, lo que generalmente significa que nadie es dueño de nada. Esta configuración nos lleva al viaje hacia
DevOps. Y quiero comenzar el viaje como cualquier viaje con un primer paso. Y el primer paso es una cita del manual de
DevOps que dice que el primer camino enfatiza el rendimiento de todo el sistema. Por lo tanto, no solo nos enfocamos en los silos de diferentes partes del trabajo o departamentos, sino en todo el sistema. Y si aplicamos esto, que es como la página uno del manual de
DevOps, tenemos nuestro antiguo sistema que va desde el desarrollo de una característica hasta el cliente, que tiene un traspaso entre los equipos de funciones y los equipos de dispositivos. Entonces preparamos algo, lo entregamos y este equipo verifica que todo esté bien. Si eso funciona, si pueden decir, está bien, llegamos al cliente. Pero hemos estado aquí antes, hemos visto esto, y ¿qué pasa si llamo a este equipo aquí desarrollo? ¿Y qué pasa si llamo a este equipo aquí operaciones? ¿No es eso muy similar? ¿No es eso exactamente lo que estaba sucediendo, digamos, hace 10, 15 años cuando los equipos de desarrollo se trataban de compartir su código lo más rápido posible sin importar si ese código estaba rompiendo la producción o si era demasiado costoso para que esa máquina funcionara las 24 horas del día, los 7 días de la semana, para tener tantas horas de tiempo de actividad? Y luego teníamos operaciones que tenían que lidiar con los equipos de desarrollo que enviaban características que ni siquiera estaban funcionando en algunos de los dispositivos, algunos de los servidores que estaban soportando. Y así teníamos este problema de traspaso y mi verdadera pregunta aquí es que, bueno, estos son muy similares, pero para impulsar este arreglo similar, ¿cómo llegamos al
DevOps que conocemos hoy? Hemos mejorado mucho en los últimos diez años, pero ¿cómo llegamos a lo que conocemos como el
DevOps de hoy? Y creo que hay muchos factores contribuyentes, uno de los cuales para mí son las abstracciones.
3. Abstracciones en DevOps para Frontend
Proveedores de servicios en la nube como AWS y Google Cloud Platform han construido abstracciones que hacen que los equipos sean más autónomos. Sin embargo, crear las abstracciones adecuadas es un tema complejo. DevOps para frontend implica abordar las diferencias en los dispositivos, como las API, el tiempo de ejecución, el motor del navegador y el reproductor de video. Para permitir que los equipos de funciones desarrollen e implementen de manera autónoma, se puede crear un equipo de plataforma para manejar estas diferencias. La primera abstracción creada se encuentra en el momento de compilación, enfocándose en herramientas estandarizadas para desarrollar y depurar en dispositivos. La automatización de pruebas y el monitoreo son cruciales, especialmente en el entorno actual de trabajo remoto. La segunda capa de abstracción se encuentra en el tiempo de ejecución, específicamente con remotos y controladores.
y las abstracciones son algo muy poderoso. Si pensamos en los proveedores de servicios en la
cloud como
AWS y Google
Cloud Platform, construyeron algunos servicios sobre servidores, sobre bases de datos, sobre muchas cosas con las que los desarrolladores y las operaciones solían lidiar de una manera muy diferente. Pero al construir estas abstracciones, pudimos hacer que los equipos sean más autónomos. Y esto no se limita solo a los proveedores de servicios en la
cloud, porque tenemos muchas herramientas como Terraform, Puppet, Ansible, todas ellas van en la dirección de hacer que las personas sean autónomas, hacer que los equipos sean autónomos. Por lo tanto, crear esta capa de abstracción sobre nuestros servidores de metal desnudo es lo que, en mi opinión, ayudó a desarrollar la cultura de
DevOps. Y la pregunta correcta que debemos hacer en este punto es si estas abstracciones fueron tan poderosas para el principio y el movimiento de
DevOps en general, ¿cuáles son las abstracciones que necesitamos en el
frontend? Encontrar la abstracción correcta es un tema muy complicado, porque las abstracciones son muy fáciles de crear de manera incorrecta. Hay una interesante charla de Alex Martelli, la torre de abstracciones, que destaca lo peligroso que puede ser a veces tomar el camino equivocado para crear una abstracción. Entonces, para responder a esa pregunta, quiero entrar en la última parte de nuestro viaje, que es
DevOps para el
frontend. Cuando pensamos en
DevOps para el
frontend, pero más importante aún, en la pregunta correcta que debemos hacer, ¿por qué nuestro equipo no puede ser autónomo? ¿Por qué no pueden trabajar en Xbox y en PlayStation 5 y en tu Samsung Tizen al mismo tiempo? Principalmente porque hay diferencias, y esos dispositivos no son iguales, están lejos de serlo. Entonces, los puntos problemáticos que tenemos en el
frontend, en este contexto específico de los dispositivos en estos días, es que cada uno de estos dispositivos tiene diferentes API, un tiempo de ejecución diferente, un motor de navegador diferente, un reproductor de
video diferente. Todas estas diferencias hacen que sea muy doloroso para un equipo enfocarse en una característica y distraerse con todas estas diferencias. Entonces, ¿qué tal si creamos algún tipo de equipo de plataforma, o un equipo que se encargue de estas diferencias e intente facilitar las diferencias entre los dispositivos? La idea es permitir que los equipos de funciones desarrollen e implementen de manera autónoma. Pero, ¿cómo lo hacemos? Porque una televisión es un dispositivo complejo en el sentido de que tienes un modo de desarrollo, un modo de depuración, y luego tienes el tiempo de compilación y estás construyendo una aplicación, luego tienes el tiempo de ejecución cuando ejecutas la aplicación usando tu control remoto o usando tu controlador. Entonces, ¿cómo abordamos eso? Lo abordamos en dos pasos. El primer paso es la primera abstracción que creamos en el momento de compilación, enfocándonos en herramientas. Desarrollar en el dispositivo es algo que debe estandarizarse, porque si estás trabajando en la última característica que deseas agregar al diseño en este caso, pero a cualquier servicio o producto que estés construyendo, desarrollar en el dispositivo es una oportunidad para detectar todos los errores de inmediato. Y si puedes desarrollar fácilmente en el dispositivo sin preocuparte por las diferencias del dispositivo, eso es una gran victoria. Pero también la depuración en el dispositivo. ¿Qué pasa si tienes un problema y quieres poner un punto de interrupción, quieres entrar en ese bucle? La depuración en un dispositivo no está estandarizada. Por lo tanto, creamos un comando
NPM run dev donde puedes pasar algunos parámetros y no importa si se está ejecutando en un PS5 o en una Xbox, porque esa complejidad se ha abstraído. Pero también trabajamos mucho en el monitoreo y especialmente nos enfocamos en la automatización de pruebas. Especialmente en este tiempo de COVID, no es fácil trabajar en dispositivos. Por lo tanto, nos enfocamos mucho en un laboratorio de televisión que tenemos donde podemos ejecutar pruebas automatizadas en las televisiones y en los propios dispositivos. Y todo eso está completamente impulsado por la automatización y por el código. Escribes tus pruebas y en lugar de ejecutarse en un navegador normal, se ejecutarán en el propio dispositivo, incluso si no está allí contigo. En tu habitación o en tu oficina en casa, están en el laboratorio de televisión, pero están ejecutando las pruebas por ti. Y eso es crucial para asegurarte de tener confianza al enviar a múltiples dispositivos. Esa fue la primera capa de abstracción. La segunda capa está en el tiempo de ejecución. Una vez que tu aplicación está en ejecución, ¿qué sucede en el tiempo de ejecución?
4. Maximizando el flujo y permitiendo la autonomía del equipo
Imagina hacer que el equipo sea autónomo obstruyendo las diferencias de dispositivos en el tiempo de ejecución. Soluciones como APIs y herramientas estandarizadas permiten a los equipos de funciones desarrollar, probar e implementar de manera autónoma. Al aplicar los principios de DevOps, hacemos que el trabajo sea visible, reducimos el tamaño de lote y evitamos que los problemas se transmitan aguas abajo. Desarrollar en el dispositivo permite solucionar errores de inmediato, y la automatización de pruebas garantiza la compatibilidad en todos los dispositivos. Maximizar el flujo y permitir la autonomía del equipo son clave.
Las primeras diferencias se encuentran en los controles remotos y los controladores. Imagina que un controlador de PlayStation debe funcionar de alguna manera de manera similar al control remoto de tu televisor, porque están controlando una aplicación, que es muy similar. Y también, los desarrolladores que están construyendo las características dentro de la aplicación no les importa si la estás usando desde una PS4 o desde un televisor. Por lo tanto, obstruir estas diferencias siempre va en la dirección de hacer que el equipo sea autónomo. Y si extendemos ese conocimiento, todas las API de los dispositivos se obstruyen en nuestro tiempo de ejecución. Entonces, los equipos que trabajan en características simplemente llaman a algo que está estandarizado. No les importan las diferencias de los dispositivos. Y esto es cierto para la API de red, ya que tratamos con videos en vivo, la red es muy importante para nosotros, pero también para poner tu aplicación en segundo plano cuando tienes una notificación y abres otro juego, tal vez en tu Xbox. Todas estas son soluciones que implementamos para permitir que los equipos de funciones sean autónomos, permitir que los equipos de funciones pasen de desarrollar su característica específica a probar y ver sus cambios en los dispositivos de nuestros clientes, con la ayuda de las herramientas y la solución del equipo de plataforma de TV. Entonces, los equipos de funciones son autónomos y llegan a los clientes. Pero la idea es que, bueno, estamos creando algunas ideas paralelas. Tenemos algunas ideas paralelas entre
DevOps y esta configuración de
frontend. ¿Podemos llevarlo aún más lejos? ¿Podemos decir, okay, tomemos algún principio de
DevOps como maximizar el flujo? Y veamos si eso se aplica. Y la respuesta es sí, se aplica. Porque cuando llevamos el flujo de principio a fin, debemos enfocarnos en hacer el trabajo visible como principio de
DevOps. Pero si tenemos un equipo trabajando en la característica, entregando valor a nuestros clientes, su trabajo es visible en un tablero de Jira. Es tan fácil como puede ser. Puedes ver el trabajo volando de una columna a otra después de que llega al cliente. Y también reducir el tamaño de lote, no tener que lidiar con dos equipos y toda la comunicación entre estos dos equipos significa que un equipo puede implementar varias veces al día. Depende de ellos. Ellos están a cargo. Son autónomos para tomar esa decisión. Y por último, pero no menos importante, evitar que los problemas se transmitan aguas abajo. Eso es posible gracias a las herramientas, gracias a las soluciones que creamos. Y si comenzamos a desarrollar en el dispositivo desde muy temprano, puedes solucionar el error de inmediato, porque ves que esa cosa redonda no es tan redonda. Tal vez quieras solucionarlo de inmediato. Y si estás desarrollando en el dispositivo, lo solucionarás en segundos, no en un sprint. Y una vez que tienes eso, puedes pasar a la automatización de pruebas, porque tal vez trabajas y desarrollas en una Xbox, y quieres asegurarte de que tu PR, tu solicitud de extracción, aún funcione en una PlayStation 5. Entonces, ¿por qué no ejecutar la prueba en nuestro laboratorio de TV para verificar que la PlayStation 5 esté bien? Eso es posible porque hemos invertido mucho en este tipo de cosas, en este tipo de herramientas para permitir que los equipos sean autónomos.
Aplicando los principios de DevOps más allá de la web
Comenzamos teniendo un tablero GR para hacer visible el trabajo. Enfócate en la experiencia del desarrollador y proporciona las herramientas adecuadas. DevOps se trata de permitir que los equipos sean autónomos. El backend es solo el comienzo. Mide para mejorar y repetir. Gracias por quedarte aquí conmigo hoy. ¿Dónde has aplicado los principios de DevOps hasta ahora? Si eres lo suficientemente flexible, puedes convencer a cualquiera de hacer cualquier cosa con DevOps. Aplicando los principios de DevOps más allá de la aplicación web. Preguntas de la audiencia.
Entonces, para resumir, ¿cómo maximizamos el flujo? Comenzamos teniendo un tablero GR para hacer visible el trabajo, especialmente en torno a las características. Y una vez que tienes un equipo que implementa con frecuencia y luego implementa de manera autónoma, realmente puedes comenzar a desarrollar en un dispositivo lo antes posible y agregar automatización de pruebas a la mezcla. Quiero dejarte con algunas ideas en orden sobre qué hacer, qué sacar de esta charla. Y quiero decir como primera cosa, que la experiencia del desarrollador es muy importante. Es probablemente aún más importante cuando tienes una experiencia realmente mala, como trabajar en dispositivos. No es tan fluido como, por ejemplo, trabajar en la web. Cuando tienes muchas más herramientas, muchas más soluciones ya implementadas. Entonces, enfocarte en tu experiencia como desarrollador es importante. Proporcionar las herramientas adecuadas, dedicar tiempo a construir esas herramientas es muy importante. Y luego,
DevOps se trata de unificar, pero más importante aún, se trata de permitir. Se trata de hacer que los equipos sean autónomos, hacer que los equipos sean responsables de principio a fin porque los equipos que son responsables pueden estar disponibles para esa característica específica, pueden respaldar esa característica con las herramientas y la solución que hemos implementado para que sean autónomos. Y luego, el
backend es solo el comienzo, porque vimos cómo estos principios particulares se aplican bastante bien, si me lo preguntas, también al
frontend, a los equipos. Y una vez que tienes todo esto configurado y en su lugar, solo tienes que medir para mejorar y repetir. Esa fue la última diapositiva. Quiero agradecerte por quedarte aquí conmigo hoy. Puedes encontrarme en Twitter en underscore max Gallo, y estas diapositivas están disponibles en GitHub, en la charla
DevOps para
Frontend. Muchas gracias. Quiero echar un vistazo a la encuesta y a la pregunta que hiciste a nuestra audiencia, y la pregunta fue, ¿dónde has aplicado los principios de
DevOps hasta ahora? Y al ver esto, la mayoría de las personas respondieron
backend y más allá. Y eso es bueno. Estoy de acuerdo, ¿verdad? Sí, sí. En realidad, esperaba la segunda opción, pero aún así estoy feliz. ¿Hay algún lugar en el que no se deban aplicar los principios de
DevOps en el mundo moderno? Creo que si eres lo suficientemente flexible, puedes convencer a cualquiera de hacer cualquier cosa con
DevOps, realmente. Al igual que tus habilidades como persona adecuada para convencer a otros de hacer cosas, pero definitivamente es posible. He tenido discusiones con empresas que me dicen, oh no, somos demasiado grandes para
DevOps. No sabes de lo que estás hablando, pero está bien. Excelente. Entonces tu charla trató sobre aplicar los principios de
DevOps más allá del navegador, ¿verdad? Más allá de la aplicación web. Y entiendo por lo que estabas hablando, que se trata de implementar aplicaciones web en televisores inteligentes y consolas de juegos y todas esas cajas inteligentes para tu aplicación, ¿verdad? Sí. Tenemos muchas preguntas de la gente, así que voy a ir poco a poco con ellas, e incluso tengo las mías propias.
Ejecución de pruebas automatizadas en consolas y televisores
En cuanto a las herramientas listas para usar, hay muy pocas opciones para ejecutar pruebas automatizadas en consolas y televisores. Cada dispositivo es como una isla, con sus propios procesos de desarrollo y experiencias. No existe un producto listo para usar para realizar pruebas en dispositivos reales, por lo que las soluciones personalizadas son comunes. Nuestro enfoque es similar al de otros, donde tenemos un laboratorio de televisores con cámaras apuntando a los televisores y decodificadores para ejecutar pruebas automatizadas.
Tenemos una pregunta de Lara. Lara pregunta, ¿qué herramientas utilizas para ejecutar pruebas automatizadas en consolas y televisores? ¿Verdad? ¿En cuántos dispositivos diferentes pruebas estas cosas? Sí. En cuanto a las herramientas listas para usar, es muy poco o casi nulo. Por mucho que amemos nuestros televisores, nuestras Playstations y nuestras Xboxes, cada uno de estos dispositivos es una isla. No se comunican entre sí. Simplemente viven en su propia burbuja con sus propios procesos de desarrollo, con su propia experiencia de desarrollo, y desafortunadamente no existe un producto que puedas comprar y decir, okay, voy a usar esto para
testing en un dispositivo real. Amazon lo ha hecho para su laboratorio de dispositivos. Netflix tiene algo al respecto. La BBC aquí en el Reino Unido tiene algo similar. Pero todos estamos hablando de soluciones personalizadas. Y en nuestro caso, optamos por una ruta muy similar.
Pruebas en televisores y equilibrio de trabajo
En nuestro laboratorio de televisores, ejecutamos pruebas automatizadas en los televisores y decodificadores utilizando cámaras. Obtener la señal de los televisores es un desafío, por lo que apuntamos la cámara a la pantalla. La variedad de televisores y decodificadores dificulta tener un método de prueba unificado. A pesar de la simplicidad de utilizar cámaras, es una solución práctica. Como ingeniero de DevOps, equilibrar el trabajo en las aplicaciones y mantener el flujo de entrega depende del día.
Así que tenemos un laboratorio de televisores donde literalmente tenemos cámaras apuntando frente a los televisores, donde ejecutamos pruebas automatizadas en los televisores y decodificadores mismos. ¿A veces es posible interceptar la señal HDMI? Por ejemplo, si tienes, por ejemplo, una PlayStation, puedes obtener la señal del HDMI. Pero si estás trabajando en un televisor, no hay realmente forma de obtener la señal del televisor. Así que simplemente apuntas la cámara hacia él. Así que hay mucho trabajo personalizado, mucho hardware involucrado en eso. Pero si me preguntas por una herramienta para comenzar a usar la próxima semana, simplemente hazlo tú mismo. No existe tal cosa. Y ese es un punto muy válido, porque, ya sabes, es relativamente fácil, especialmente, hablamos de containers y como, oh, lanzar algo en un contenedor, funciona en todas partes. Pero hay tantos televisores diferentes ahí arriba. Vale, podemos decir que hay dos o tres o cuatro consolas, pero tantos televisores y modelos de televisores, decodificadores y demás. Así que puedo imaginar que es muy difícil tener un método de prueba unificado para todos ellos. Pero sí, me gusta el hecho de que tengas cámaras apuntando a las cosas allí. Muy tangible. Parece la respuesta que un niño de cinco años podría dar. ¿Cómo lo pruebo? Sí, es fácil. Solo apunta la cámara a la pantalla. Pero eso es completo. Eso está bien. Eso funciona. Mientras funcione, está perfectamente bien. Exactamente. La solución más fácil que se puede pensar. Correcto. Genial. Excelente. Así que otra pregunta que llega. Como ingeniero de DevOps , lo que sea que eso sea, no vamos a entrar en eso, una persona que hace DevOps, en realidad, ¿cómo divides tu tiempo entre trabajar en una aplicación y mantener todo tu flujo de entrega? Esa es una buena pregunta. Depende del día. A veces hay días muy ocupados cuando todo
Inversión en herramientas para pruebas en televisores
Invertimos en herramientas para ser autosuficientes y eficientes en las pruebas en televisores. Dedicamos tiempo adecuado para mejorar la experiencia. Utilizamos pruebas de regresión visual, pero no conectadas a la cámara. La señal de la cámara es poco confiable, por lo que la utilizamos para el modo piloto virtual. Tenemos una aplicación basada en web para el control manual y pruebas automatizadas impulsadas por código. Las cámaras se utilizan bajo demanda en el laboratorio. Las cámaras se pueden ver de forma remota, lo cual es útil cuando se trabaja desde casa.
está en rojo. No, solo estoy bromeando. En nuestro sentido, en la transición en la que nos estamos moviendo ahora mismo, al menos dentro de la zona, estamos invirtiendo bastante como empresa en muchas herramientas y muchas de esas cosas que nos ayudarían a ser más autosuficientes y en general más eficientes, porque en la televisión, de lo contrario tendrías que probar todo manualmente, lo cual tiene, como puedes imaginar, sus propias limitaciones. Así que eso está bastante integrado en nuestros objetivos como empresa para asegurarnos también de que eso es algo que queremos hacer. Afortunadamente, sé que eso no siempre es así cuando tienes el respaldo de tu empresa. A veces, lo haces en tu tiempo libre o intentas meterlo en un sprint, porque no es el punto principal. Pero en nuestro caso, afortunadamente, tenemos tiempo adecuado dedicado a eso. Así que dependiendo de la semana, podría ser una semana en la que nos centramos en entender por qué la PS5 se desconecta de la red y ya no es accesible. Pero en general, se trata de mejorar la experiencia. Todo lo que hacemos, se trata de mejorar tu trabajo diario, que es una de las cosas más valiosas que puedes hacer.
Sí, absolutamente. Quieres recuperar tu tiempo. Excelente. Tenemos un par de nuevas preguntas que llegan. Una pregunta de D. ¿Cómo sabes si la prueba ha pasado o ha fallado a través de la cámara? ¿Tienes alguna forma visual muy clara de definir eso? Esa es una muy buena pregunta. Tenemos algunas pruebas de regresión visual, pero aún no están conectadas a la cámara. La razón más simple del mundo es que la señal de la cámara pasa por otras IP y la calidad de la señal de la cámara puede degradarse fácilmente por cualquier motivo, como ratones que saltan sobre el cable de Internet o algo que sucede en el otro lado del mundo. Así que se ha demostrado que no es confiable. Por lo tanto, no utilizamos la señal de la cámara para obtener los resultados de las pruebas. Las cámaras se utilizan principalmente en lo que llamamos modo piloto virtual. Así que en realidad hay una URL a la que puedes acceder con una aplicación basada en web que te permite controlar el televisor manualmente. Esa es la parte manual. Y luego está la parte automatizada, que en cambio está impulsada por código. Escribes tus pruebas como si las estuvieras ejecutando en una experiencia de navegador normal, y escribes tus expectativas y todo como lo haces normalmente en el navegador, pero las cámaras se utilizan principalmente para un uso bajo demanda de este tipo de televisores en el laboratorio.
De acuerdo. ¿Y puedes ver esas cámaras, supongo, de forma remota, verdad? Mencionaste que están basadas en IP, por lo que nadie tiene que estar en el laboratorio de pruebas o hacer esas cosas. No, no. Exactamente. Pero ha sido un desafío. Ha sido muy útil durante los tiempos de COVID porque, como muchas personas, estamos trabajando desde casa. Y si trabajas para una empresa que tiene que admitir, como por ejemplo, si eliges Samsung Tizen, eso son como cinco o seis versiones diferentes.
Desafíos de las pruebas en televisores en el laboratorio
Es desafiante tener múltiples televisores para las pruebas y depender del laboratorio ha demostrado ser difícil. Los equipos dedican mucho tiempo y esfuerzo para mantener el laboratorio en funcionamiento. Esto brinda tangibilidad a las pruebas, a diferencia de las pruebas de código que son abstractas.
De acuerdo. Entonces, no voy a tener seis televisores de 50 pulgadas en mi casa como todos los demás. Así que eso es bastante desafiante. Esa fue una solución bastante útil, especialmente durante estos tiempos, pero también ha demostrado ser difícil porque cada vez que hay un problema de hardware, tienes que ir al laboratorio. Es un poco ingenuo pensar que el laboratorio se arreglará solo, que funcionará por sí mismo. Hay mucho trabajo y mucho tiempo que uno de nuestros equipos dedica a ello, tratando de hacer que funcione para todos los demás equipos. Para mí, esto es fascinante porque nuevamente le das mucha tangibilidad a las cosas que pruebas, como cuando probamos código, es algo muy abstracto, así que eso está perfectamente bien. De acuerdo. Hay otra pregunta que llega, los dispositivos en los que trabajas, ¿tienen algún tipo de sandbox o API de depuración? ¿Estos dispositivos te ayudan con eso o depende completamente de ti? Para algunos de ellos, sí, ofrecen una forma de interactuar con el depurador, obtener un perfilador de memoria o, lo más importante, interceptar, tener una forma segura de interceptar las solicitudes de red. En nuestro caso, es muy específico de lo que Dozondos, como empresa de transmisión de soporte en vivo, está bastante involucrado con la red y los países y la geolocalización como proveedor global. Así que cada vez que probamos, necesitamos probar para un país específico con conexiones de red específicas o una configuración de red específica. Estos tipos de cosas a veces están disponibles, a veces no. Y lo que tratamos de hacer es ofrecer el conjunto mínimo de herramientas para que un desarrollador simplemente use la plataforma. Estamos agregando algunas herramientas de terceros para probar, como winery u otras que se sienten un poco antiguas para la web. Si eres un ingeniero de frontend puro basado en el navegador, esas cosas son de alrededor de 2010 más o menos. Pero en la televisión, todavía están en funcionamiento. Todavía existen, como ese pequeño javascript que te dará acceso a una especie de depurador de Chrome donde aún puedes hacer cosas bastante útiles. Y en nuestro esfuerzo por reducir las diferencias entre dispositivos, tratamos de hacer que estas herramientas y estas adiciones para tu experiencia de desarrollo estén disponibles, especialmente en las plataformas donde las nativas no son compatibles. Sí, puedo imaginar. Hay muchas otras cosas que necesitas construir para que esto funcione correctamente. Sí. Bueno, excelente. Max, muchas gracias. Muchas gracias por compartir tus conocimientos. Muchas gracias por compartir las respuestas que tienes aquí, respondiendo a las preguntas de las personas, y también he aprendido algo hoy. Esperamos verte pronto de nuevo en DevOps.js Gracias de nuevo por tenerme aquí.
React Summit 2023
Comments