El día que rompí React Native

Rate this content
Bookmark

4 de noviembre de 2022 - Era solo un día normal para el "equipo de lanzamiento" mientras nos preparábamos para preparar el primer candidato a la liberación para React Native 0.71. Poco sabíamos cómo un lanzamiento inocuo podría haber desencadenado un efecto dominó que resulta en compilaciones fallidas para casi todos los desarrolladores de React Native.


Con la sabiduría de la retrospectiva, repasaremos lo que sucedió, cuáles son nuestras lecciones aprendidas y los puntos bajos de este incidente. Tendremos la oportunidad de mirar a través de las entrañas de React Native, descubrir nuestra cultura de respuesta a incidentes y aprender cómo estamos fortaleciendo nuestro ecosistema para protegernos contra eventos similares en el futuro.  


Únete a mí mientras revivimos este incidente, y no pierdas esta oportunidad de obtener información, inspirarte y abrazar las lecciones aprendidas del día que rompí React Native.

30 min
08 Dec, 2023

AI Generated Video Summary

La charla discute un incidente en el que un lanzamiento de React Native provocó compilaciones fallidas y cómo se solucionó. El incidente ocurrió debido a que el paquete NPM se volvió demasiado grande, lo que llevó al traslado de los artefactos de Android a Maven central. El uso de versiones dinámicas y la dependencia plus en React Native se identificaron como factores contribuyentes al problema. Las lecciones aprendidas incluyen la importancia de eliminar las dependencias plus y la necesidad de mejores recomendaciones para crear bibliotecas resistentes.

1. El Día Que Rompí React Native

Short description:

Hola a todos. Hoy quiero contarles una historia de un lluvioso día de noviembre del año pasado en Seattle. La gente comenzó a informar sobre compilaciones de React Native rotas, y descubrimos que una próxima versión de React Native estaba causando el problema. Yo, Nicola Corti, ingeniero de Android en Meta, les guiaré a través del incidente y cómo lo solucionamos.

Hola a todos. Así que hoy quiero contarles una historia. Es la historia de un lluvioso día de noviembre del año pasado. Estaba en Seattle. Si alguna vez han estado en Seattle, asegúrense de visitar la Starbucks Reserve Roastery. Es un Starbucks especial donde hacen catas de café. Si te gusta el café, definitivamente querrás echarle un vistazo. Y yo estaba allí. Estaba revisando mi correo electrónico, revisando mis notificaciones de GitHub. Y sí, todo parecía genial. Pero luego la gente comenzó a enviarme mensajes de que por alguna razón sus compilaciones, sus compilaciones de React Native estaban rotas. Y bueno, estaba en Discord. Así que déjame ver qué está pasando realmente.

Y en React Native, ejecutarás Android para ejecutar la aplicación Android. Y la gente comenzó a informar sobre mensajes de error de la nada, de una manera realmente terrible. Imagina que tu compilación estaba funcionando hace un minuto, luego vuelves a compilar, no haces ningún cambio de código y tu compilación está rota. Esto es terrible desde el punto de vista de la experiencia del desarrollador. Y obviamente no debería suceder. Luego comenzamos a investigar, oye, ¿por qué estas compilaciones se están rompiendo realmente? Y nos dimos cuenta de que en el mensaje de error, se mencionaba una próxima versión de React Native, como 0.710.rc0. E incluso para los usuarios que estaban en versiones anteriores de React Native, como en 68 y 69 y así sucesivamente. En ese punto, nos dimos cuenta, sí, creo que tenemos un problema. Y personalmente tuve un gran problema porque se suponía que debía volar de regreso a Londres en un par de horas. Entonces, ¿cómo lo solucionamos?

Así que mi nombre es Nicola Corti. Trabajo como ingeniero de Android en el equipo de React Native en Meta. Y hoy estoy emocionado de contar la historia del día en que rompí React Native. Para entender completamente qué fue esto, les guiaré a través de lo que sucedió, qué fue el incidente real, por qué se rompió y cómo lo solucionamos realmente. Así que la advertencia aquí es, bueno, el incidente fue en Android, pero efectivamente rompimos la compilación para todos. Así que bueno, no muchas personas aquí usan React Native, pero confíen en mí, hay muchas lecciones aprendidas que se aplican a cualquier tecnología. Así que comencemos con lo que sucedió. Dentro de React Native y dentro del equipo de React Native, tenemos este grupo de personas llamado el equipo de lanzamiento.

2. Proceso de Lanzamiento de React Native

Short description:

El equipo responsable de los lanzamientos de React Native ejecuta el script Bump.OSS version con la próxima versión. El primer candidato a la liberación, RC0, se envía para pruebas. En 0.71, el paquete NPM se volvió demasiado grande, lo que llevó a la mudanza de los artefactos de Android a Maven central.

Son responsables de elaborar nuevas versiones de React Native cada cuatro a seis meses. Y lo que hacen, lanzan el script desde la consola, que se llama Bump.OSS version, con la próxima versión que tienen la intención de lanzar. Cuando cortamos una nueva rama, hacemos el RC0, que es el primer candidato a la liberación. El primer candidato a la liberación generalmente es inestable. Simplemente lo cortamos y lo enviamos al mercado para que la gente pueda comenzar a testing y decirnos si hay problemas de integración o regresiones. Así que 0.71, que fue a principios de este año, en realidad, fue bastante grande, y hubo muchos cambios dentro.

3. Traslado de los artefactos de Android a Maven Central

Short description:

Un cambio realmente relevante para este incidente es este RFC 508, que es la solución fuera del paquete NPM para los artefactos de React Native. El paquete NPM de React Native se estaba volviendo demasiado grande, por lo que decidimos mover los artefactos de Android del paquete NPM a Maven Central. El incidente ocurrió porque el paquete se estaba volviendo demasiado grande, y tuvimos que eliminar los binarios del paquete NPM.

Un cambio que es realmente relevante para este incidente es este RFC 508, que está fuera de la solución del paquete NPM para los artefactos de React Native. Prácticamente hablando, el paquete NPM de React Native se estaba volviendo demasiado grande. Ya no podíamos caber allí, y entraré en ello en un minuto. Pero tuvimos que encontrar una solución alternativa donde se pudieran enviar los artefactos de Android.

Cuando haces nativo, no solo distribuyes código, distribuyes binarios, y esos binarios se vuelven bastante grandes, y pueden llegar a cientos de megabytes. Así que decidimos mover los artefactos de Android del paquete NPM a Maven Central, que es donde generalmente se distribuyen las bibliotecas de Android. Así que este sitio web, que es bastante arcaico a juzgar por la cantidad de CSS que utilizan, es en realidad Maven Central. Así que no es más que básicamente un cubo S3 donde se almacenan las bibliotecas de Android. Y aquí es donde se almacena en realidad React Native y la gente que construye React Native lo obtiene de allí. Y si miras en la lista de versiones, verás que, bueno, solíamos publicar en Maven Central en el pasado. Si miras las versiones entre 0.11 y 0.20, que es como 2015, 2016, solíamos publicar allí. Pero luego en algún momento nos mudamos porque publicar en Maven Central era demasiado complicado, y entonces dijimos, está bien, hagamos un paquete monolítico y pongamos todo dentro del paquete de React Native. Bueno, entonces tuvimos que revertir esta decisión porque el paquete se estaba volviendo demasiado grande y publicamos 0.71.0.rc0, que ves justo debajo de allí, publicado en noviembre de 2022. Aquí.

Así que intentemos entender por qué ocurrió el incidente en primer lugar. Porque hasta ahora parece razonable. Cuando estábamos publicando en Maven Central en el pasado, volvíamos allí porque el paquete se estaba volviendo demasiado grande. Por qué las cosas se rompieron. Así que volvamos a este RFC y miremos más de cerca dentro del paquete npm. Como dije, la carpeta de Android era la mayor infractora aquí. Estamos hablando de 66 megabytes y en 0.71 estábamos añadiendo símbolos de debug y más cosas para mejorar la experiencia del desarrollador de Android, lo que hizo que el paquete de npm se hiciera más grande. Estaba llegando a más de 200 megabytes. Curiosamente, no puedes publicar paquetes de npm que superen los 220 megabytes o así porque npm te devolverá HTTP 4.1.3 contenido demasiado grande. Así que npm simplemente no era una opción. Así que tuvimos que eliminar esos binarios del paquete npm. El problema subyacente que desencadenó este incidente es lo que llamamos una dependencia plus, que es realmente similar a una dependencia de estrella en npm. Así que para Android, usamos Gradle para construir, y dentro del archivo Gradle tenemos un bloque donde describimos cuáles son nuestras dependencias, como qué bibliotecas queremos depender. Y una de estas es React Native. Esta cadena aquí se llama coordenadas maven gav. Sé que esto es muy específico para Android, pero también es bastante fácil de entender.

4. Entendiendo gav y Versiones Dinámicas

Short description:

gav significa grupo, artefacto y versión. La plantilla predeterminada para las aplicaciones de React Native incluye archivos Gradle con comentarios interesantes. Un comentario suprime una advertencia por el uso de versiones dinámicas, que se consideran un antipatrón en el espacio de Android. Las versiones dinámicas pueden llevar a compilaciones irreproducibles y dependencia de los mantenedores de la biblioteca.

Entonces, gav significa grupo, que es la organización que publica una biblioteca, a para artefacto, que es el nombre de la biblioteca, y v para versión, que en este caso era más, lo que significa simplemente obtener la versión más alta que encuentres en cualquier repositorio y usarla.

Bueno, si miramos como esto es de la plantilla predeterminada. Entonces, cuando creas una nueva aplicación de React Native, tendrás como archivo Gradle y cosas como esos comentarios aquí, que creo que son un poco interesantes.

Entonces, por ejemplo, hay un comentario aquí justo arriba que dice no inspección Gradle versión dinámica. Esto es una supresión de una advertencia para la línea justo debajo. La línea de abajo contiene un más, que, bueno, en el espacio de Android es un antipatrón. Específicamente, hay esta página en la documentación de Gradle, que se llama manejo de versiones con cambios a lo largo del tiempo. Entonces, como versiones dinámicas. Y solo en la primera, como si tomo una captura de pantalla de esta página, tienen dos advertencias que te dicen que las versiones dinámicas no son geniales porque simplemente llevan a compilaciones irreproducibles. Básicamente estás a merced del mantenedor de la biblioteca. Si el mantenedor de la biblioteca mañana publica una nueva versión, simplemente la vas a obtener y tal vez tu compilación se rompe de la noche a la mañana. Entonces, no es genial, ni en NPM ni en ninguna otra plataforma que tenga un concepto similar.

5. Entendiendo la Dependencia Plus en React Native

Short description:

Para entender por qué ocurrió el problema, necesitamos mirar la dependencia plus en React Native. Anteriormente, la dependencia se obtenía del paquete NPM, pero luego se trasladó a otro repositorio. La dependencia plus recupera la versión más alta disponible, causando problemas cuando se publica una versión superior. Esto llevó a que los proyectos utilizaran la versión 0.71.0.rc0, lo que causó problemas.

Pero, ¿por qué funcionó? Para entender completamente, necesitamos ver este otro comentario a la derecha, que dice de node modules. Así que la dependencia plus funcionó hasta React Native 0.70 porque en realidad estábamos obteniendo la dependencia del paquete NPM. Si empiezas a mirar lo que hay dentro de node modules, React Native, añade la carpeta Android, veremos que básicamente allí tenemos una colección de artefactos. Tenemos como un sources.jar, un archivo pom y así sucesivamente. Esto es como cosas de Java que se utilizan para construir las aplicaciones Android. Estoy fingiendo un poco aquí, como que la lista es en realidad bastante más larga. Pero independientemente de eso, esta es la lista de artefactos que utiliza React Native para construir una aplicación Android, como el núcleo de React Native. Y si miras en Maven Central, ese es en realidad el mismo contenido. Así que simplemente movimos esa carpeta de node modules a otro repositorio. Así que ahora tal vez empieces a entender por qué ocurrió el problema. El problema ocurrió porque la dependencia plus significa obtener la más alta. Y mientras añadas solo una versión localmente dentro de tus node modules y una versión en Maven Central, que era menor, en este caso 0.20, las cosas funcionaban bien. Pero si publico algo en Maven Central o en cualquier otro repositorio que tenga una versión superior, esa versión prevalecería en todos los proyectos de este planeta. Así que la gente empezó a agarrar esa versión 0.71.0.rc0, lo cual no es genial.

6. Arreglando las Compilaciones de React Native

Short description:

Para solucionar el problema, lanzamos parches para todas las versiones de React Native hasta la 0.63. Esto requirió un esfuerzo significativo, ya que tuvimos que trabajar con ramas de lanzamientos realizados hace años. Fuimos más allá para proporcionar una versión parcheada de React Native que solo incluía las correcciones necesarias. Además, nos pusimos en contacto con Sonotype, la empresa que administra Maven Central, para que se eliminaran los artefactos. Aunque llevó algún tiempo, esta fue la solución definitiva al problema. De esta experiencia, aprendimos la importancia de eliminar las dependencias plus.

Entonces, veamos cómo lo solucionamos realmente. ¿Cómo podemos arreglar las compilaciones para todos? Entonces, podrías pensar, está bien, entonces voy a mi proyecto y simplemente elimino el plus, ¿no? Especifico la versión que estoy usando, como 0.68, ¿no? Como si hubiera parcheado mi proyecto local. Bueno, eso es cierto, pero también un poco ingenuo porque en React Native, dependemos mucho de las dependencias externas, como en todos los proyectos node. Por ejemplo, una biblioteca muy popular para React Native es reanimated, una biblioteca de animación. Y también tienen un archivo griddle. Y dentro de su archivo griddle, también dependen de React Native. Y bueno, reanimated no quiere depender de una versión específica de React Native, solo quieren obtener la que el usuario está usando. Así que también tienen una dependencia plus en su archivo griddle. Eso significa que incluso si tu proyecto especifica 68, reanimated diría como, no, no, no 68, dame la más alta, quiero esa. Así que básicamente cada biblioteca estaba contribuyendo a romper el proyecto aún más.

¿Entonces cómo lo arreglamos? Básicamente estaba en el avión, esperando a despegar y abrí un problema en GitHub tratando de explicar cuál es el problema, y con una combinación de paquetes de parches y demás, cómo podemos mitigar efectivamente este problema en tu proyecto. Pero esto no era ideal, el hecho de que tuvieras que usar el paquete de parches o hacer ediciones locas en tu carpeta de módulos node no es ideal. No deberías estar haciendo eso. Así que, junto con el resto del equipo de lanzamiento y personas de la comunidad, lanzamos parches para todas las versiones de React Native hasta la 0.63. Y esto fue un gran esfuerzo, porque imagina que tienes una rama para un lanzamiento que hiciste hace tres años. No sabes si el CI está funcionando, no sabes cuál es el estado allí. Y quieres intentar lanzar una nueva versión desde allí. No es fácil. Bueno, lo logramos y realmente hicimos un esfuerzo extra, la gente trabajó toda la noche para arreglarlo de manera que solo tendrías una versión parcheada de React Native que contiene solo las correcciones necesarias para resolver el problema. Y bajamos hasta la 63 porque mantenemos un ojo en la cuota de mercado de las diversas versiones de React Native que ustedes descargan de NPM. Y 63 nos permitió cubrir el 99% de las descargas. Así que básicamente pudimos arreglarlo para todos. La solución definitiva, en realidad, fue contactar a Sonotype, que es la empresa que administra Maven Central y pedirles que eliminaran los artefactos. Esto llevó un poco más de tiempo, como dos días, porque inicialmente pensamos, está bien, nunca van a eliminar eso. Como Maven Central es un almacenamiento de datos inmutable, no se supone que debas eliminar bibliotecas. Pero en este caso, esta fue la única solución a este problema. Así que también nos ayudaron mucho en arreglar esto.

Ahora quiero compartir un par de lecciones aprendidas, cosas que yo y el resto del equipo de lanzamiento y el equipo de React Native nos llevamos de esta experiencia. Entonces, primero, muchas de las dependencias plus han sido eliminadas.

7. Soporte de React Native y Cultura de Incidentes

Short description:

Hemos implementado soluciones en nuestra infraestructura de Android e iOS para prevenir problemas similares. Ahora tenemos una ventana de soporte de lanzamiento que declara qué versiones de React Native admitimos. Esto cubre casi el 70-75% de la cuota de mercado y proporciona una ventana de un año para recibir parches y actualizaciones de seguridad. Reconocemos que nuestro tiempo de respuesta al incidente fue lento en este incidente de código abierto. En Meta, utilizamos niveles SEV para expresar la gravedad de un incidente, siendo SEV2 el nivel para problemas mayores. Las bibliotecas también contribuyen al problema al copiar patrones que pueden contener anti-patrones.

Como tenemos soluciones en marcha dentro de nuestra infraestructura tanto de Android como de iOS para prevenir problemas similares a este. Y también hemos considerado implementar lo que se llama una ventana de soporte de lanzamiento. Históricamente, se recomendaba estar en la última versión de React Native, lo cual sí funciona, pero no siempre es posible porque tu proyecto puede quedarse un poco atrás. Así que ahora somos más intencionales sobre qué versiones de React Native son realmente compatibles. Si miras en el grupo de trabajo de lanzamientos de React Native para React, verás que declaramos qué versiones de React Native admitimos. Y cuando decimos que admitimos, queremos decir que si encuentras un error en una de esas versiones, nos comprometemos a solucionarlo y lanzar un parche para ti. Esto cubre casi el 70, 75% de la cuota de mercado hasta ahora. Y esto permite cubrir un año entero de lanzamientos. Así que eso significa que aunque deberías actualizar tu versión de React Native y cualquier versión de dependencia que uses, tienes una ventana de un año para poder recibir siempre parches y parches de seguridad y demás.

Otra cosa que aprendimos es el tiempo de respuesta a incidentes. Personalmente creo que fuimos bastante lentos para responder aquí. El problema es que este fue un incidente de código abierto. No tenemos ninguna telemetría en React o React Native, así que no sabemos cómo van las cosas para ti. Como no sabemos si tus compilaciones están rotas. No sabemos qué dependencias usas y así sucesivamente. Así que el hecho de que alguien me dijera que su compilación está rota, no tengo la sensación de que esto significa que todas las compilaciones en el planeta están rotas. Así que quiero tocar un poco la cultura de incidentes en Meta para que entiendas cómo intentamos integrarnos dentro de la cultura de Meta y el espacio de código abierto. En Meta, utilizamos niveles SEV, que son como un estándar de mercado para expresar la gravedad de un incidente. Tenemos SEV4, que es el nivel más bajo, que es solo un aviso. Abrimos un incidente SEV4 siempre que hay algo que podría romperse, pero tal vez no. Por ejemplo, hicimos una gran migración de la estructura del monorepo de React Native, y siempre que mueves mucho código, las cosas pueden romperse. Por eso abrimos un SEV4 para ese caso. Tenemos SEV3, que significa problema significativo, la resolución es de moderada a alta prioridad, como algo se rompió, alguien debería mirarlo. SEV2, que es un problema mayor, la resolución es de muy alta prioridad, como un grupo significativo de personas se ve afectado. SEV1, alerta roja, todos a bordo, como generalmente uno de los productos de Meta está caído. Y luego SEV0, que significa crisis a nivel de empresa, como varios productos están caídos o las cosas están realmente mal. En este caso, esto fue un SEV2 porque todo el ecosistema de código abierto de React Native estaba roto, y tuvimos que despertar a la gente y encontrar una solución lo antes posible.

Otra cosa que nos llevamos a casa son las mejores prácticas de las bibliotecas. Como dije antes, las bibliotecas estaban contribuyendo a exacerbar el problema aquí porque cada una tiene su propia lógica de construcción, y pueden hacer, básicamente lo que pasa es que hay patrones en la comunidad que se copian. Tal vez empiezas una nueva biblioteca y copias otra biblioteca, y tal vez hay un anti-patrón allí que se pasa de una biblioteca a otra.

8. Inversión en la Creación de la Biblioteca React Native

Short description:

Estamos invirtiendo en la creación de la biblioteca React Native para proporcionar mejores recomendaciones para la creación de bibliotecas resilientes. Lecciones aprendidas: evitar los envíos los viernes, la liberación tuvo suerte de ocurrir durante el fin de semana, y los incidentes en un avión son desafiantes. Lee el análisis post-mortem en el blog de React Native para obtener más detalles técnicos.

Es por eso que estamos invirtiendo en la creación de la biblioteca React Native, que es nuestro punto de entrada para crear nuevas bibliotecas. Hay un RFC abierto en el sitio web, que es la plantilla dorada para la creación de la biblioteca React Native. Así que queremos ofrecer mejores recomendaciones que estén aprobadas por Meta sobre cómo crear bibliotecas para React Native que sean resilientes a incidentes como este.

Y luego, bueno, un par de otras lecciones aprendidas que son bastante personales, pero se aplican a todos, creo. El día en que se invocó este script, fue un viernes. Así que incluso si estás trabajando en móviles, no hagas envíos los viernes. Y bueno, en este caso particular, en realidad, si miras la rama de lanzamiento de React Native 71, cada vez que ves un número de versión de revert bump, es un intento de publicar una versión que falló y se reinició. Sí, para ser justos, se suponía que este lanzamiento se iba a realizar el martes, y luego pasaron al jueves, y luego al viernes, y asumieron que todo funcionaría. Bueno, ese no fue el caso. Creo que en este escenario particular, en realidad, el hecho de que lanzáramos el viernes fue suerte. Tuvimos mucha suerte de que un problema como este surgiera durante el fin de semana para que tuviéramos tiempo durante el fin de semana para preparar lanzamientos de parches para todas las versiones de React Native en el mercado. Pero si esto hubiera ocurrido el lunes por la mañana, habríamos interrumpido el flujo de trabajo de los bancos, de las personas que están usando React Native en producción, y no pueden debido a problemas como este. Así que creo que ahora no hacemos lanzamientos los viernes por si acaso. Pero en este caso particular, tuvimos suerte.

Y la otra cosa es que, el Wi-Fi de los aviones es realmente terrible. Y asegúrate de no tener que lidiar con incidentes en un avión porque especialmente si necesitas transferir grandes binarios como artefactos para móviles, bueno, te va a llevar una eternidad. Así que si estás interesado en aprender más sobre este incidente, en realidad publicamos un análisis post-mortem en el blog de React Native. Puedes leerlo. Entra en más detalles sobre las tecnicidades de este problema. Y con esto, quiero agradecerte mucho por escuchar.

9. Republicación en Maven y Eliminación de Versiones

Short description:

Mi única pregunta es, ¿cómo volviste a publicar en Maven o no lo hiciste? Volvimos a publicar en Maven con nuevas coordenadas, cambiando el nombre de la biblioteca a React Android. Implementamos alias para resolver las solicitudes de React Native a React Android. Se siguió el proceso de eliminar paquetes y publicar nuevas versiones. La respuesta de Sanatype fue positiva, y encontraron interesante la necesidad de eliminar una versión.

Mi única pregunta es, ¿cómo volviste a publicar en Maven o no lo hiciste? No. Entonces, sí, volvimos a publicar en Maven. Como que ahora las bibliotecas están en Maven Central. Y básicamente lo que hicimos, usamos nuevas coordenadas. Así que la biblioteca ya no se llama React Native, se llama React Android y sí. Sí, eso lo solucionará. Sí. Y también implementamos todas las cosas de alias. Entonces, si en tu archivo Gradle solicitas React Native, en realidad vamos a redirigir esa solicitud para resolver React Android. Sí, sí, porque creo que esa es una de las soluciones que es como, realmente no es posible ponerlo en el mismo lugar. Como que no creo que hubiera una solución rápida, es una de esas cosas que no tenías una solución rápida. Absolutamente.

Solo mira el profundo agujero del WiFi de Lufthansa. Estaba mirando a través de los como Sanatype usa Jira para interactuar con los clientes. Sí. Lo siento mucho por eso. No me sorprende. Básicamente, estaba mirando las solicitudes para eliminar paquetes y siempre estaban respondiendo como, no, nunca eliminamos nada. Solo publica una nueva versión de la biblioteca. Como si hubieras hecho una publicación falsa, puedes aumentar la versión. Sí, eso también es cierto en NPM y también en Crate para Rust, es lo mismo. Sí. Y yo estaba como, cada vez que publico, solo empeoraría esta situación. Como porque, ya sabes, hay esa versión que está ofendiendo porque su fuerza es mayor que las demás. Así que simplemente elimínalo. Y ellos fueron geniales en hacer eso. Creo que lo miraron y estaban como, ¿sabes qué? Nunca pensé que encontraría una razón por la que necesitaba eliminar una versión. Sí, como que encontré una. Absolutamente. Estaban como, su respuesta fue como, oh, eso es realmente interesante.

10. Lecciones Aprendidas y Pruebas Manuales

Short description:

Una de las lecciones aprendidas es no reutilizar cosas del pasado sin entender completamente las razones detrás de su uso. Mentalmente, me siento bien ahora, aunque hubo un momento de pánico. Pudimos solucionar el problema con la ayuda de mis colegas. Sin embargo, enfrentamos desafíos al parchear React Native 0.63 debido a las dependencias de software obsoletas. Es importante tener imágenes de docker del entorno de compilación para evitar fallos de compilación causados por cambios en las versiones de las herramientas. También tenemos un proceso de pruebas manuales y confiamos en las pruebas de CI y las pruebas internas en la infraestructura de materia.

Lo siento mucho. Pero sí, fueron realmente útiles en esto. Y sí, una de las lecciones que obtuvimos de esto es también no intentar reutilizar cosas que usaste en el pasado. Básicamente, quiero decir, en este caso, deberíamos haber hecho más arqueología de Git para entender completamente por qué se usaba Maven Central en ese momento. ¿Por qué ya no se usa? Como que pensamos, OK, está ahí, simplemente sigue reutilizándolo. Pero sí, volvió a surgir.

¿Cómo te sientes mentalmente ahora que ha pasado un tiempo desde que ocurrió eso? Bueno, está bien. El día que estaba como, oh, Dios mío, esto es realmente malo. Como, sabes, en la masterclass estoy como si estuviera en los negocios. Pero tuve suerte y estaba como, OK, intentemos solucionar lo máximo posible. Y como le pregunté a mi colega, estaban en ese momento en Andover, lo cual sí, quiero decir, pudimos solucionarlo. Pero durante el fin de semana, nos quedamos despiertos e hicimos todos los parches. Y realmente como un problema allí es como para cuando estaba diciendo como para hacer un parche de React Native 0.63, necesitas Xcode 13, y luego CircleCI es como, no, eliminé Xcode 13. Este es como software obsoleto. ¿Por qué lo necesitas? Y yo estoy como, necesito publicar una biblioteca de hace tres años. Y necesito Xcode 13 porque esto se construye solo con Xcode 13 y así sucesivamente. Así que creo que otra lección aprendida aquí, solo más técnica y en el lado de Android y Android e iOS, intenta tener imágenes de docker de tu entorno de compilación, porque si tú compilas allí en el CI, básicamente tan pronto como cambien la versión de Java o la versión de Node o cualquier versión de cualquier herramienta en ese entorno, ya no puedes compilar. Para Android, tenemos imágenes de docker por lo que puedo bajar a, no sé, versiones antiguas de React Native y decir como, OK, reconstruye eso.

Todos aparecieron. Todos aparecieron ahora. OK. OK. OK. Eso es grande. Lo siento por eso. Entonces, ¿tienes una prueba manual testing? Oh, ¿tienes un proceso de prueba manual testing antes de lanzar nuevas versiones? Sí, lo hacemos. Tenemos una serie de pruebas de CI, principalmente pruebas unitarias. Confiamos mucho en las pruebas internas que ejecutamos en la infraestructura de materia. Entonces, por ejemplo, cada vez que envías una solicitud de extracción contra React Native, la importamos internamente y ejecutamos Oculus contra ella. Ejecutamos Facebook contra ella.

11. Lanzamiento y Optimización de React Native

Short description:

Al lanzar React Native, probamos que puedes crear un proyecto e iniciar la aplicación de inmediato. Meta consume React Native desde la fuente, mientras que el código abierto tarda más tiempo en construirse. Nuestro objetivo es un rendimiento óptimo.

Entonces, si rompiste algo gravemente, lo descubriremos. Pero cuando hacemos un nuevo lanzamiento de React Native, probamos que eres capaz de crear un proyecto, que la nueva aplicación se inicia y así sucesivamente, porque la forma en que se utiliza React Native en código abierto e internamente en Meta es ligeramente diferente. Meta consume React Native desde la fuente, desde la principal. Entonces tus cambios van directamente a la aplicación de Facebook que sale la próxima semana. Mientras que para el código abierto, mientras se construye React Native lleva tiempo. Tienes más cuidado. Sí, quiero decir, obviamente, queremos asegurarnos de que con una línea de código, eres capaz de crear una nueva aplicación e iniciarla de inmediato sin depender de los cachés de compilación o algo así. Entonces, sí, simplemente intentamos hacerlo lo más óptimo posible.

12. Incidente SEV Zero y Reacción

Short description:

¿Alguna vez has recibido un SEV cero? Afortunadamente, nunca había recibido un SEV cero. En octubre de 2022, los servidores estaban caídos, y fue un incidente SEV cero. Me alegro de trabajar en móviles porque los incidentes en ese espacio no son tan graves como los de los servicios de producción. No hubo una cultura de culpabilidad alrededor del incidente, y la reacción fue arreglarlo lo más pronto posible para la comunidad de código abierto. Nos propusimos proporcionar la mejor solución e incluso consideramos crear versiones de parche para React Native para llegar a tantos usuarios como fuera posible.

Una pregunta más, ya que la cosa no aparecía, que es, ¿alguna vez has recibido un SEV cero? Y si es así, ¿cómo lo manejaste, cómo lo manejó alguien? ¿Alguien lloró? Así que nunca había recibido un SEV cero. Gracias. Afortunadamente. Pero si recuerdas, creo que en octubre de 2022, creo. Oh, los servidores estaban caídos o algo así. Sí, como que todo estaba caído. Como creo que Meta se cortó de internet y eso fue un SEV cero. Varias personas estaban despiertas y totalmente manos a la obra en eso. Me alegro de trabajar en móviles. Como siempre veo el Android. Así que los incidentes son bastante locos. Como si eso empieza a fallar, bueno, está bien, puedo hacer un nuevo lanzamiento y ponerlo en la tienda. Pero pasarán horas antes de que esté fuera, ¿sabes? Así que me alegro de no ser ingeniero de producción. No soy un SRE. Estoy de guardia a veces por cosas como el soporte de código abierto y cosas que necesitan atención inmediata o escenarios como este. Pero la gravedad de los problemas de código abierto que podemos tener nunca es tan alta como los servicios que están en producción.

OK, así que solo una más, porque siento que ganaste mucha tracción. Básicamente preguntaba si alguien se enfadó contigo. ¿Cuál fue la reacción de tu líder y compañeros de equipo? Espero que muchas otras empresas de tecnología allá afuera, no tengamos una cultura de culpabilidad alrededor de los incidentes. Los incidentes pueden suceder. En realidad no estaba en el equipo de lanzamiento. Como no envié ese script, no era responsable. Pero en realidad, escribí la infraestructura que causó esto. Así que me sentí responsable, obviamente. La reacción fue como, sí, rompimos cosas. Arreglémoslo lo más pronto posible, porque nos importa mucho nuestra community de código abierto. Así que intentemos darles la mejor solución. Como cuando añadimos esos fragmentos y parches por ahí, era como, seguro. ¿Pero podemos hacerlo mejor? ¿Podemos hacer versiones de parche para las versiones de React Native hasta el 99 por ciento de los usuarios? Sí, podemos.

13. Lecciones Aprendidas y Preguntas y Respuestas

Short description:

Al final del día, se aprendieron muchas lecciones. La lección aprendida es dejar de suprimir las advertencias y apuntar a cero advertencias. Si tienes más preguntas, hay una sala de preguntas y respuestas disponible. Por favor, regresa en nueve minutos para la innovación en el panel de React.

Así que hagámoslo. Entonces, sí, quiero decir, al final del día, se aprendieron muchas lecciones. Y sí, como no me han despedido por esto. Y creo que lo último que quiero decir es, ¿no es la lección aprendida para realmente dejar de suprimir las advertencias? Sí, sí. Soy un gran fan de ir a cero advertencias. No más TS ignores. Eso podría solucionarlo. Parpadea dos veces si estás a salvo. Sí, OK, seguro, seguro. En realidad, no parpadeaste. Está bien, estoy a salvo. Estoy a salvo. Estoy a salvo. Genial. Creo que hemos terminado. No, hemos terminado. Sí, pero él no parpadeó. Así que ahora estoy asustado. Parpadeé dos veces. OK, genial. Confía en mí. OK, sí. Entonces, si tienes más preguntas de nuevo, lamento el retraso que ocurrió aquí después. Sí, hay una pequeña sala de preguntas y respuestas allí. Y por favor, regresa en. Oh, eso no tiene el tiempo para hacerlo. Nueve minutos porque vamos a tener una innovation en el panel de react. Entonces, sí. Nos vemos a todos en nueve minutos.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Advanced Conference 2023React Advanced Conference 2023
29 min
Raising the Bar: Our Journey Making React Native a Preferred Choice
At Microsoft, we're committed to providing our teams with the best tools and technologies to build high-quality mobile applications. React Native has long been a preferred choice for its high performance and great user experience, but getting stakeholders on board can be a challenge. In this talk, we will share our journey of making React Native a preferred choice for stakeholders who prioritize ease of integration and developer experience. We'll discuss the specific strategies we used to achieve our goal and the results we achieved.
React Finland 2021React Finland 2021
27 min
Opensource Documentation—Tales from React and React Native
Documentation is often your community's first point of contact with your project and their daily companion at work. So why is documentation the last thing that gets done, and how can we do it better? This talk shares how important documentation is for React and React Native and how you can invest in or contribute to making your favourite project's docs to build a thriving community
GraphQL Galaxy 2022GraphQL Galaxy 2022
31 min
Your GraphQL Groove
Building with GraphQL for the first time can be anywhere between daunting and easy-peasy. Understanding which features to look for in your client-side and server-side tooling and getting into the right habits (and ridding yourself of old habits) is the key to succeed with a team of any size in GraphQL.

This talk gives an overview of common struggles I've seen numerous teams have when building with GraphQL, how they got around common sources of frustration, and the mindset they eventually adopted, and lessons learned, so you can confidently stick with and adopt GraphQL!
DevOps.js Conf 2024DevOps.js Conf 2024
25 min
Atomic Deployment for JS Hipsters
Deploying an app is all but an easy process. You will encounter a lot of glitches and pain points to solve to have it working properly. The worst is: that now that you can deploy your app in production, how can't you also deploy all branches in the project to get access to live previews? And be able to do a fast-revert on-demand?Fortunately, the classic DevOps toolkit has all you need to achieve it without compromising your mental health. By expertly mixing Git, Unix tools, and API calls, and orchestrating all of them with JavaScript, you'll master the secret of safe atomic deployments.No more need to rely on commercial services: become the perfect tool master and netlifize your app right at home!

Workshops on related topic

React Advanced Conference 2022React Advanced Conference 2022
81 min
Introducing FlashList: Let's build a performant React Native list all together
WorkshopFree
In this workshop you’ll learn why we created FlashList at Shopify and how you can use it in your code today. We will show you how to take a list that is not performant in FlatList and make it performant using FlashList with minimum effort. We will use tools like Flipper, our own benchmarking code, and teach you how the FlashList API can cover more complex use cases and still keep a top-notch performance.You will know:- Quick presentation about what FlashList, why we built, etc.- Migrating from FlatList to FlashList- Teaching how to write a performant list- Utilizing the tools provided by FlashList library (mainly the useBenchmark hook)- Using the Flipper plugins (flame graph, our lists profiler, UI & JS FPS profiler, etc.)- Optimizing performance of FlashList by using more advanced props like `getType`- 5-6 sample tasks where we’ll uncover and fix issues together- Q&A with Shopify team
React Summit 2022React Summit 2022
117 min
Detox 101: How to write stable end-to-end tests for your React Native application
WorkshopFree
Compared to unit testing, end-to-end testing aims to interact with your application just like a real user. And as we all know it can be pretty challenging. Especially when we talk about Mobile applications.
Tests rely on many conditions and are considered to be slow and flaky. On the other hand - end-to-end tests can give the greatest confidence that your app is working. And if done right - can become an amazing tool for boosting developer velocity.
Detox is a gray-box end-to-end testing framework for mobile apps. Developed by Wix to solve the problem of slowness and flakiness and used by React Native itself as its E2E testing tool.
Join me on this workshop to learn how to make your mobile end-to-end tests with Detox rock.
Prerequisites- iOS/Android: MacOS Catalina or newer- Android only: Linux- Install before the workshop
React Summit Remote Edition 2021React Summit Remote Edition 2021
60 min
How to Build an Interactive “Wheel of Fortune” Animation with React Native
Workshop
- Intro - Cleo & our mission- What we want to build, how it fits into our product & purpose, run through designs- Getting started with environment set up & “hello world”- Intro to React Native Animation- Step 1: Spinning the wheel on a button press- Step 2: Dragging the wheel to give it velocity- Step 3: Adding friction to the wheel to slow it down- Step 4 (stretch): Adding haptics for an immersive feel
React Advanced Conference 2023React Advanced Conference 2023
159 min
Effective Detox Testing
Workshop
So you’ve gotten Detox set up to test your React Native application. Good work! But you aren’t done yet: there are still a lot of questions you need to answer. How many tests do you write? When and where do you run them? How do you ensure there is test data available? What do you do about parts of your app that use mobile APIs that are difficult to automate? You could sink a lot of effort into these things—is the payoff worth it?
In this three-hour workshop we’ll address these questions by discussing how to integrate Detox into your development workflow. You’ll walk away with the skills and information you need to make Detox testing a natural and productive part of day-to-day development.
Table of contents:
- Deciding what to test with Detox vs React Native Testing Library vs manual testing- Setting up a fake API layer for testing- Getting Detox running on CI on GitHub Actions for free- Deciding how much of your app to test with Detox: a sliding scale- Fitting Detox into you local development workflow
Prerequisites
- Familiarity with building applications with React Native- Basic experience with Detox- Machine setup: a working React Native CLI development environment including either Xcode or Android Studio
React Summit 2023React Summit 2023
88 min
Deploying React Native Apps in the Cloud
WorkshopFree
Deploying React Native apps manually on a local machine can be complex. The differences between Android and iOS require developers to use specific tools and processes for each platform, including hardware requirements for iOS. Manual deployments also make it difficult to manage signing credentials, environment configurations, track releases, and to collaborate as a team.
Appflow is the cloud mobile DevOps platform built by Ionic. Using a service like Appflow to build React Native apps not only provides access to powerful computing resources, it can simplify the deployment process by providing a centralized environment for managing and distributing your app to multiple platforms. This can save time and resources, enable collaboration, as well as improve the overall reliability and scalability of an app.
In this workshop, you’ll deploy a React Native application for delivery to Android and iOS test devices using Appflow. You’ll also learn the steps for publishing to Google Play and Apple App Stores. No previous experience with deploying native applications is required, and you’ll come away with a deeper understanding of the mobile deployment process and best practices for how to use a cloud mobile DevOps platform to ship quickly at scale.
React Advanced Conference 2022React Advanced Conference 2022
131 min
Introduction to React Native Testing Library
Workshop
Are you satisfied with your test suites? If you said no, you’re not alone—most developers aren’t. And testing in React Native is harder than on most platforms. How can you write JavaScript tests when the JS and native code are so intertwined? And what in the world are you supposed to do about that persistent act() warning? Faced with these challenges, some teams are never able to make any progress testing their React Native app, and others end up with tests that don’t seem to help and only take extra time to maintain.
But it doesn’t have to be this way. React Native Testing Library (RNTL) is a great library for component testing, and with the right mental model you can use it to implement tests that are low-cost and high-value. In this three-hour workshop you’ll learn the tools, techniques, and principles you need to implement tests that will help you ship your React Native app with confidence. You’ll walk away with a clear vision for the goal of your component tests and with techniques that will help you address any obstacle that gets in the way of that goal.you will know:- The different kinds React Native tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting text, image, and native code elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RNTL tests and how to handle them- Options for handling native functions and components in your JavaScript tests
Prerequisites:- Familiarity with building applications with React Native- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Native Testing Library- Machine setup: Node 16.x or 18.x, Yarn, be able to successfully create and run a new Expo app following the instructions on https://docs.expo.dev/get-started/create-a-new-app/