Una Guía Breve para el Desarrollo de React Native

Hola a todos. Gracias por tenerme hoy. Mi nombre es Motez y trabajo como defensor del desarrollador en Bit-Trice. Principalmente, todos los días ayudo a los desarrolladores móviles a tratar de entender cuáles son los desafíos a los que se enfrentan, especialmente con aplicaciones cross-platform o aplicaciones nativas. Hoy estamos hablando sobre la implementación móvil. Como sabemos, si estás trabajando con aplicaciones React Native, al final tienes dos aplicaciones nativas, iOS y Android. Y, como sabemos, cada aplicación requiere flujos de trabajo, pasos o configuraciones específicas. Por lo tanto, los desarrolladores de React Native se enfrentan a diferentes requisitos, procesos y flujos de trabajo para iOS y Android. Entonces, necesitas descubrir cómo puedes hacerlo automáticamente porque necesitas firmar la aplicación antes de usarla en la App Store. Como sabemos, no es como una aplicación web. Necesitas firmar tu aplicación o certificado o perfil de aprovisionamiento o secretos y luego poder lanzarla en la App Store.

Configuración compleja, como mencionamos, también las pruebas. ¿Deberíamos ejecutar las pruebas de UI en cada solicitud o deberíamos dejarlo antes del lanzamiento? ¿Cómo podemos ejecutarlo? ¿Qué marco estamos usando? ¿Deberíamos ejecutar las pruebas unitarias y de UI y todo para cada solicitud? Entonces, ¿cómo podemos lidiar con este proceso? Y también lanzamientos lentos. Tal vez haya una empresa que lanza cada dos meses, lo cual es enorme. Porque si tienes un negocio y tienes diferentes competidores en el mercado, si quieres lanzar una nueva característica, este es un proceso largo o largo para lanzar cada dos meses. Entonces, necesitamos tratar de eliminar el proceso durante al menos dos semanas. Como una cadencia de lanzamiento de dos semanas. Y CI inflexible y frágil. No pierdas tu tiempo solucionando los problemas del servidor de CI y cómo podemos lidiar con los diferentes problemas con la CI todos los días. Aquí, Scott Hanselman de Microsoft, como gerente de programa, dijo que la herramienta más poderosa que tenemos como desarrolladores es la automatización. La automatización no es solo las pruebas de UI. Es la automatización para todo. Puede automatizar el despliegue, los lanzamientos, la revisión de código o cualquier cosa que podamos, debemos automatizar el proceso. Entonces, el objetivo es gastar menos tiempo en tareas que ralentizan o dificultan al desarrollador y centrarse más en entregar las características. Porque como sabemos, las horas del desarrollador son el enfoque principal o las cosas más importantes para las empresas. Por eso, creo que el proceso que solucionará estos problemas o desafíos será un proceso de Mobile DevOps o un proceso de mobile CICD. Entonces, comenzamos con una estrategia de CICD y luego pasamos a la fase de medición o planificación. Y luego tenemos la estrategia para un CICD. Y luego estamos construyendo y testing

Después de lanzar y construir nuestras aplicaciones móviles. Y luego estamos monitoreando nuestras aplicaciones móviles. No es como si simplemente lo lanzáramos en la App Store. No, hay otra etapa para monitorear las aplicaciones móviles. Por ejemplo, si deseas monitorear los bloqueos de la aplicación o el rendimiento de la aplicación en general. Entonces, una vez que lanzas tus aplicaciones móviles, tienes otra herramienta o proceso para comenzar a revisar y monitorear el lanzamiento de la aplicación móvil. Aquí tenemos seis pasos para la adopción de desarrolladores móviles. Como mencionamos, planificación, estrategia de CICD, construcción, pruebas, lanzamientos beta. Esto es especialmente para móviles. Porque tal vez para web no tenemos... tal vez a veces estamos hablando en una implementación web sobre implementación canary o como azul-verde. Pero esto es necesario para aplicaciones móviles, que son lanzamientos beta que estás lanzando a tus probadores beta para verificar que todo funcione correctamente en tu aplicación. Y esto puede ser para pruebas de vuelo, por ejemplo, para iOS o para la distribución de aplicaciones Firebase o para la App Store, para un canal interno. Y lanzamientos en producción. Y luego tenemos un monitoreo. Entonces, aquí, asumamos que este es como el proceso completo. Entonces, estoy tratando de averiguar cómo podemos automatizar este proceso. Por ejemplo, simplemente creas un código o lo envías a GitHub o cualquier repositorio de código fuente que estés usando, se genera la solicitud. Tal vez tengas un servidor de CI. Y se activa la construcción del servidor de CI. Y luego pasas por el proceso de integración continua, que es clonar el repositorio de código, clave SSH para acceder al código. Y luego comienza la instalación, como sabemos, las aplicaciones React Native requieren, por ejemplo, si estás usando ER. Luego puedes ejecutar el análisis de código estático. Este será el primer paso. Luego puedes ejecutar pruebas unitarias e integradas. Y tal vez tengas un informe de cobertura. Y luego, si todo está bien, verificará errores. Entonces, esta es la primera etapa. Esto es para React Native o tal vez

para la aplicación de JavaScript o TypeScript. Luego tienes un constructor de iOS. A partir de aquí, comenzamos a diferenciar entre iOS y Android. Y como mencioné, hay requisitos totalmente diferentes. Entonces, por ejemplo aquí, tal vez necesitas ejecutar o instalar como comenzar instalando las dependencias de KukuBots, luego la construcción de Xcode y luego la firma automática de código. Hay un mecanismo o un paso para la firma automática de código o la firma automática de la aplicación. Y al final, tendrás el IP. Luego, después de eso, puedes ejecutar las pruebas de interfaz de usuario de extremo a extremo. Tal vez pueda ser con Detox, que es el framework que admite aplicaciones React Native, o tal vez puedas usar Appium, esto es de código abierto para aplicaciones móviles. Y luego estás subiendo los artefactos. Luego, si todo está bien, ahora estamos continuamente como haciendo las etapas o paso a paso. E incluso si tenemos un problema, digamos que tenemos un problema en la etapa de integración continua , tal vez en la prueba de unidad e integración. Esto será útil para el equipo porque en esta etapa, encontraste el problema temprano. Entonces, si estás ejecutando pruebas de interfaz de usuario o pruebas de unidad o integración y luego se bloquea o tienes un problema, entonces lo descubrirás en las etapas tempranas en el desarrollo, por lo que todavía estamos en la solicitud de extracción. Entonces, puedes imaginar que este problema es el cliente lo encuentra en la App Store o en la aplicación después de lanzar la aplicación móvil. Entonces, necesitas lanzar otra versión o una corrección rápida y necesitas hacer este proceso nuevamente desde cero. Entonces, esto nos ayuda a fallar rápidamente. Entonces, este es como un concepto de fallar rápidamente. Entonces, estamos fallando rápidamente y aquí estamos avanzando un cambio en las pruebas y ejecutando una prueba en etapas tempranas en el desarrollo de código para evitar cualquier otro problema o problema en la vida o la producción. Esto es lo mismo para iOS, solo son diferentes cosas aquí, estamos usando diferentes comandos, por ejemplo, para Android, estamos ensamblando o ejecutando la tarea de depuración del paquete debug que es nos dará la aplicación y luego estamos firmando nuestra aplicación, firmando nuestra aplicación y luego también será lo mismo para ejecutar la prueba de interfaz de usuario o ejecutar la prueba de extremo a extremo. Con la implementación continua, aquí, tal vez podamos ejecutar como implementar en la distribución de la tienda de aplicaciones de Firebase o en Google Play Store. Aquí, encontraremos otro desafío. Entonces, ¿deberíamos ejecutar todas estas cosas en secuencia, como ejecutar la construcción de iOS primero y luego ejecutar Android en un flujo de trabajo? Este será el problema, por lo que puede llevar tiempo. Entonces, ahora, debemos pensar en otro desafío después de implementar una solución de CI/CD, que son los pipelines. Entonces, podemos ejecutar diferentes flujos de trabajo en paralelo al mismo tiempo, por ejemplo, supongamos que el primero es el flujo de trabajo uno que era la integración continua para ejecutar una unidad de jQuery. Entonces, podemos ejecutarlo primero, si está en verde, entonces, podemos iniciar iOS y Android en paralelo al mismo tiempo, para ahorrar tiempo porque ahora, si estamos ejecutando esto y antes de los lanzamientos, esto llevará tiempo. Entonces, ahora, podemos pensar en los pipelines de construcción. Y también tenemos otra opción. Puedes implementar o usar Fastlane. ¿Alguien aquí usa Fastlane? Ok. Entonces, Fastlane es una herramienta basada en Ruby

El archivo FASTA. Es un archivo de configuración en Ruby. Se llama archivo FASTA. Entonces, con el archivo FASTA, puedes configurar todo como una tarea o como una acción. Por ejemplo, aquí en Android, en la sección de Android, puedes, por ejemplo, enviar una nueva versión beta a Crashlytics o a Firebase. Y para Android, por ejemplo, puedes tener una tarea específica para subirla a TestFlight para los probadores beta. Así que aquí puedes tener una tarea o acción. Se llama acción y eso. Entonces, tienes diferentes carriles como encontramos aquí. Así que la descripción, este es el carril. Así que tenemos un carril llamado beta y un carril llamado implementado. Y para iOS, también tenemos el carril beta. Así que puedes agregar un número incrementable, que es porque estás lanzando una nueva compilación. O tomar capturas de pantalla para los metadatos o para la App Store y también implementarla en la App Store, puedes tener otra tarea para esto.

Entonces, ahora, para solucionar este problema o los desafíos a los que nos enfrentamos, debemos pensar en si debemos usar servidores dedicados o nuestra infraestructura para CI/CD. Como mencionamos anteriormente en los desafíos, tenemos un problema que a veces tenemos un servidor de CI con problemas de configuración. Por lo tanto, es posible que debas comenzar a pensar en CI/CD en la nube o integración continua en la nube. Debido a la configuración de proyectos sencilla, simplemente puedes clonar tu proyecto en GitHub y comenzar a construirlo. Realmente hace que el entorno sea especialmente para móviles, por lo que puedes imaginar si tienes un entorno limpio y cada vez que instalas en una máquina virtual o si tienes un entorno predefinido que incluye todas las herramientas que estás utilizando para tu aplicación móvil, esto ahorrará tiempo, seguro. Y los flujos de trabajo personalizables, como sabemos, tenemos flujos de trabajo diferentes para iOS y Android, firma de código sin problemas para iOS y Android y pruebas de unidad e integración automatizadas, hay diferentes pasos que pueden ayudarte en este proceso. Y distribuir aplicaciones React Native es fácil. Entonces, al final, la idea es que Mobile DevOps es una mentalidad. Pero debemos ponernos de acuerdo como equipo en qué proceso o qué plataforma debemos usar. Es una mentalidad, cultura, proceso y herramientas. CI/CD es un proceso de coordinación entre los diferentes equipos para eliminar cualquier barrera entre las operaciones, el desarrollo, el producto, y así sucesivamente. Esta automatización es una parte vital de Mobile DevOps. Y es un viaje, no un destino. Como sabemos, es un trabajo acumulado durante tal vez un año para llegar a este ciclo completo del proceso. Y gracias. Gracias. Gracias.