Ajustando DevOps para las Personas sobre la Perfección

Rate this content
Bookmark

La demanda de DevOps ha aumentado en los últimos años a medida que más organizaciones adoptan tecnologías nativas de la nube. La complejidad también ha aumentado y una mentalidad de "cero a héroe" deja a muchas personas persiguiendo la perfección y FOMO. Esta sesión se centra en cambio en por qué tal vez no deberíamos adoptar una práctica tecnológica y cómo a veces los equipos pueden lograr los mismos resultados priorizando a las personas sobre la automatización y controles de operaciones. Veamos las cantidades y el ajuste fino de todo como código, solicitudes de extracción, DevSecOps, Monitoreo y más para priorizar el bienestar del desarrollador sobre la perfección de la optimización. Puede ser una decisión válida desplegar menos y dormir mejor. Y finalmente examinaremos cómo la práctica manual y la disciplina pueden ser la clave para productos y experiencias superiores.

Julie Ng
Julie Ng
33 min
25 Mar, 2022

Comments

Sign in or register to post your comment.

Video Summary and Transcription

DevOps es un viaje que varía para cada empresa, y el trabajo remoto hace que la transformación sea desafiante. Las solicitudes de extracción pueden ser frustrantes y lentas, pero historias de éxito como la empresa de Mateo Colia muestran los beneficios de desplegar todos los días. Los desafíos con las herramientas y las vulnerabilidades requieren una consideración y priorización cuidadosas. Invertir en documentación y personas es importante para flujos de trabajo eficientes y crecimiento del equipo. La confianza es más importante que el control excesivo al desplegar en producción.

Available in English

1. Introducción a DevOps

Short description:

Hola, mi nombre es Julie. Estoy aquí para hablarles hoy en DevOps JS sobre DevOps. Quiero enfocarme más en las personas en lugar de solo en la teoría y el papel. Esta es mi opinión basada en mi experiencia, no una guía completa. Usaré ejemplos para ilustrar mis puntos.

Hola, mi nombre es Julie. Estoy aquí para hablarles hoy en DevOps JS sobre DevOps. Y yo quiero hacer algo un poco diferente. Quiero enfocarme más en las personas en lugar de digamos solo en DevOps en teoría y en papel. Entonces, antes de comenzar, tengo que mostrar brevemente una advertencia de que estoy aquí como yo misma y gran parte de lo que voy a compartir con ustedes hoy es mi opinión basada en mi experiencia. Entonces, tampoco es una guía completa para DevOps para esta charla y la duración del tiempo. He decidido elegir un par de

2. Experiencia y Enfoque hacia DevOps

Short description:

He estado construyendo para la web durante mucho tiempo, trabajando en startups, empresas corporativas y como freelance. Me uní a Alianz Alemania, trasladé proyectos a la nube. Aprendí mucho sobre DevOps a gran escala. Ahora soy ingeniero en Microsoft, especializado en arquitectura en la nube y automatización de DevOps. DevOps es un viaje, diferente para cada empresa. El trabajo remoto hace que la transformación sea desafiante. Las mejores prácticas no son obligatorias. Se trata de personas y éxito en la entrega de un producto y el crecimiento de un equipo.

ejemplos para ilustrar los puntos que quiero hacer. Entonces, he estado construyendo para la web durante mucho tiempo. Un poco más viejo de lo que parezco, y he trabajado en todos los lugares desde startups hasta corporaciones completas. Fui autónomo durante mucho tiempo, así que en realidad estuve trabajando como freelance en varias empresas y esa fue mi primera exposición a DevOps.

Luego me uní a Alianz Alemania, que es una compañía de seguros multimillonaria, y trasladamos algunos proyectos a la cloud en menos de un año. Fue una locura, pero aprendí mucho no solo sobre DevOps, las habilidades, sino realmente a scale. Ya conocía muchas de esas prácticas y especialmente alrededor de Git y despliegues automatizados, pero transferir esos a través del equipo es mucho más difícil de lo que suena. Hoy, soy ingeniero en Microsoft, parte del programa FastTrack para Azure, donde ayudo a los clientes a incorporarse a Azure. Me especializo en cloud architecture y DevOps automation. No solo les ayudamos con la mejor práctica orientación. Si se encuentran con un gran problema o un challenge, también les ayudamos a desbloquearlos. Algunos del contenido aquí va a ser de esos escenarios de clientes, así como internos Microsoft, algo así como mi historia, mi experiencia, por eso es mi opinión, no un tipo de como aquí es cómo deberías hacerlo. La razón es porque DevOps es un viaje. Cada empresa va a ser un poco diferente. Están comenzando en diferentes lugares. Siempre tienes diferentes personas con diferentes preferencias y simplemente como trabajan. Así que no importa si traes a alguien como yo que ha estado haciéndolo durante una década, depende del equipo, los procesos de la empresa, y tienes que hacer que todo esto funcione juntos.

Esto es un poco diferente de algunas de las charlas que doy. Parte de ello es que este es el segundo año en COVID. Hacer muchas de estas cosas que tienen que ver con la transformación y la transformación cultural es realmente difícil cuando todo es remoto. A veces nunca has conocido a tu equipo. Nunca he conocido a mi equipo. Así que algunas de las cosas de las que voy a hablar en términos de best practices en realidad se vuelven mucho más desafiantes cuando no tienes ese tiempo cara a cara para tener ese tipo de matices y es como, okay, ¿está hablando en serio, o es ella solo siendo su sarcástica? Y luego algunas de esas reglas, especialmente con security, ¿cómo puedo doblar algunas de ellas y por qué? Así que vamos a ver eso. Lo que quiero que obtengas de hoy es una gran cantidad de estas cosas que son best practices, incluso si estoy diciéndote que lo son, pero no tienes que hacerlas. No tienes que hacerlas hoy. No tienes que hacerlas la próxima semana. Tienes que llegar allí eventualmente y también puedes llegar allí sin seguir algunas de esas best practices. Así que no se trata de herramientas. Va a ser acerca de las personas. Y las personas van a ser la diferencia entre el éxito tanto en la entrega de un producto como en el crecimiento de un equipo, invirtiendo en un equipo que todavía estará contigo en un año o 10. Así que sin más preámbulos, comencemos.

3. Desafíos con las Solicitudes de Extracción

Short description:

A todos les encantan las solicitudes de extracción. Es la mejor práctica, pero también puedes hacerlo mal. Las solicitudes de extracción pueden ser frustrantes y lentas. Pueden crear un atasco de solicitudes de extracción. La solicitud de extracción es como la seguridad del aeropuerto, diseñada para la comunidad de código abierto.

Bueno. Entonces, lo primero, las solicitudes de extracción. A todos les encantan las solicitudes de extracción. ¿Verdad? Es la mejor práctica. Pero también puedes hacerlo mal. Digamos que tenemos un flujo de trabajo de solicitud de extracción. Todos están trabajando en una rama, ¿verdad? Puedes estar acostumbrado a, simplemente voy a abrir la rama principal de nuevo, fusionar mi flujo de trabajo y empujar, y va a ser como, nope, el servidor podría rechazar eso. Entonces tienes que abrir una solicitud de extracción, y haces tus commits, haces todas estas cosas, y luego podrías tener una convención o flujo de trabajo establecido que dice, voy a poner hashtag sign off. Un robot debería fusionar esto ahora. No funcionó. Déjame hacer eso de nuevo. Déjame es con lo que tengo que lidiar en el trabajo. A veces simplemente te rindes, ¿verdad? Y podrías no incluso cerrar la solicitud de extracción. Hay tantos repositorios con docenas o cientos de solicitudes de extracción. Es un poco frustrante porque quieres ayudar, quieres contribuir, pero no va a ninguna parte, ¿verdad? Está un poco atascado. Ahora, incluso si las solicitudes de extracción están entrando y las compilaciones están corriendo, eventualmente puedes conseguir que code se fusione. Pueden ser realmente lentas, y eso también es igual de frustrante y decepcionante. Entonces, esto es lo que una solicitud de extracción podría parecer. En documentation, suena realmente fácil. Abrir, aprobar, cerrar y fusionar. Entonces, podrías tenerlo realmente vinculado a un pipeline y tienes que esperar a un agente de compilación. Si tienes muchas personas y no tienes tantos agentes de compilación, no compraste esos que realmente necesitas, esperarás para siempre. Entonces, si eres como yo, coges tu teléfono y dices, déjame mirar Twitter, veamos qué está pasando. Vuelves y cuando finalmente se ejecutó, oh, falló. Pero es como media hora, una hora después, déjame ir a almorzar, déjame volver. Eso tampoco es necesariamente súper productivo, ¿verdad? Entonces, lo que terminas teniendo es como este atasco de solicitudes de extracción. Y eso no es necesariamente útil tampoco. Entonces, me encanta este tweet de Keith y él está hablando de las solicitudes de extracción, por qué las tienes, y es la mejor manera de describir cuándo no deberías tenerlas. Y eso es la solicitud de extracción es como la seguridad del aeropuerto, ¿verdad? Cuando se introdujo por primera vez, fue realmente diseñado más para la comunidad de código abierto y quieres dar la bienvenida a la contribución externa,

4. Procesos de Colaboración y Revisión de Código

Short description:

No se trata solo de seguridad, ¿verdad? Se trata de discutir un cambio de código y el flujo de trabajo donde la gente se queda atascada. Las solicitudes de extracción sirven como puertas a las ramas protegidas, pero a veces las cosas se rompen, lo que lleva a repositorios con numerosas solicitudes de extracción atascadas. Esto puede ser frustrante y perjudicial, obstaculizando la entrega de valor empresarial. Sin embargo, hay historias de éxito como la empresa que ayudó Mateo Colia, que ahora despliega todos los días en lugar de cada dos semanas.

¿verdad? Grandes y pequeños. Y quieres introducir una forma de colaborar en eso. No es solo acerca de seguridad, ¿verdad? Se trata de discutir un cambio de código, oh, ¿qué quieres decir con esto, puedes hacer ese cambio? Pero si estás en el mismo equipo, ¿necesitas todas esas puertas? Quizás no, ¿verdad? Entonces, veamos cómo es realmente este flujo de trabajo y dónde se queda la gente atascada, ¿verdad? Entonces, este es en realidad un diagrama que uso en el trabajo, y está en la documentación de Azure. Y si miras esa primera parte, verás que esa solicitud de extracción es una puerta a esa rama protegida, la rama principal o la rama de producción. Y a menudo también veo a personas que bloquean eso por completo, incluso los administradores no pueden empujar directamente a ella. Así que realmente estás atascado en este flujo de trabajo de solicitud de extracción. El problema aquí es que todo eso se hace en código, ¿verdad? Y nadie es perfecto. Yo tampoco. Y a veces esas cosas se rompen por cualquier motivo. Y entonces lo que terminas teniendo es en realidad algo como esto. Así que borré todo lo que no puedes ver. Y tomé esta captura de pantalla esta mañana, y me puso realmente triste, ¿verdad? Hace 26 días, esa fue la última vez que alguien contribuyó a este repositorio. Es algo interno que teóricamente como ingenieros deberíamos estar usando todos los días, ¿verdad? Hay cosas en él porque Azure cambia todos los días. Hay bugs en él. La gente debería ir a corregir errores tipográficos y enlaces rotos, etc. Pero lo que está sucediendo es que verás que tenemos unas 50 solicitudes de extracción que están atascadas. Como este repositorio está, en mi opinión, un poco como si se hubiera descontrolado. Son demasiadas. Y también ves como el número de bifurcaciones que tenemos para un equipo que en realidad solo son unos pocos cientos de ingenieros en todo el mundo. Suena como mucho. Pero en el esquema de Microsoft o en la escala de Microsoft, no es mucha gente.

Lo que realmente quieres evitar, porque es la peor sensación del mundo, es esa frustración. Porque lo que sucede es que te detienes. Y cuando te detienes, no estás entregando valor empresarial. Y eso es realmente perjudicial, ¿verdad? Eso es cuando la herramienta no te está ayudando. De hecho, te está perjudicando. Así que este es un gran tweet de Mateo Colia, que está en el equipo central de Node.js. Y realmente me encantó. Y estaba hablando de, OK, ayudó a esta empresa, y estaban desplegando cada dos semanas. Era un despliegue nocturno. Muy largo. Y lo están haciendo

5. Desplegando Todos los Días y los Desafíos

Short description:

¿Cómo desplegar todos los días? Elimina las barreras y confía en tu equipo. No siempre es sencillo. Los despliegues en la vida real no siempre son perfectos. A veces se considera arriesgado desplegar durante el horario comercial. Comienza con un horario de despliegue menos frecuente y ajústalo según tus necesidades.

todos los días ahora. Entonces, ¿cómo? ¿Cómo podrían hacer eso todos los días? Y el punto clave es que en realidad tú eliminas esas barreras. Y confías en tu equipo, ¿verdad? Ellos pueden desplegar cuando estén listos. Así que eso suena realmente simple, ¿verdad? Pero, ¿es súper simple? ¿Cómo se ve eso? Así que saqué esta foto realmente antigua de Allianz, ¿verdad? Entonces, ¿qué significa cuando estás listo para desplegar? Entonces piensas, oh, es cuando tenemos pruebas. Todo está en verde. Bueno, ¿adivina qué? En la vida real, no todo es genial. No todo siempre es genial. Y una de las cosas que fue muy interesante fue que a veces, y nunca vi esto en realidad

6. Desplegando Durante Horas Laborales y Control de Acceso

Short description:

Desplegar durante las horas laborales puede verse como un riesgo para las aplicaciones internas. Comenzar con despliegues menos frecuentes, como cada dos semanas o incluso mensualmente, es aceptable. El control de acceso es esencial para la seguridad, pero es importante encontrar un equilibrio. Julie comparte un ejemplo de una vulnerabilidad que no se abordó de inmediato, destacando la necesidad de una consideración y priorización cuidadosas. Las alertas de Dependabot proporcionan asistencia automatizada para identificar problemas.

en startups tanto, lo vi más en realidad en esta gran corporación. La gente decía que era demasiado arriesgado desplegar durante las horas laborales para una aplicación interna de línea de negocio. Entonces, sigamos trabajando ocho horas pero cambiemos todo y hagámoslo cuando nadie más lo esté utilizando. Y eso está bien para el comienzo. Créeme, no es un objetivo. Creo que solo hicimos eso una vez con pizza y tengo que borrar las caras porque, sí, GDPR. Entonces, realmente depende de los equipos. Al principio, no necesitas desplegar 10 veces al día. Está bien comenzar cada dos semanas. Está bien comenzar cada mes si estás lidiando con una aplicación heredada que, ya sabes, te está generando mucho dinero, simplemente lleva ese tiempo. Entonces, otro ejemplo que es más complicado, especialmente cuando estás como, oh, control de acceso. ¿Por qué tenemos control de acceso? Lo tenemos por seguridad. Entonces, ya sabes, ¿quién no quiere seguridad? Pero suena demasiado fácil. Vamos a repasar este ejemplo de cómo tal vez es demasiado, o tal vez no reaccionamos a ello. Entonces, estaba dando, en realidad, un webinar la semana pasada, y estoy demostrando cómo usar seguridad y qué no. Y nadie dijo realmente, Julie, pero mira eso. Hay una vulnerabilidad. ¿Por qué no la estás mirando? Desearía que me preguntaran. Pero no lo hicieron. Así que vamos a repasar. Y te diré por qué todavía está ahí, y va a permanecer ahí por el momento. Así que entro en las alertas de Dependabot. Así que todo esto es automatizado. Oye, Julie, encontramos estos problemas. Deberías solucionarlos. Uno de ellos es realmente alto. Así que el de abajo, para globparent. Ahora si lo abrimos, Dependabot, que fue comprado por GitHub, está tratando de ser útil. Aquí tienes. Es solo que la versión es inferior a 5.1.2. Así que actualízala, y deberías estar bien.

7. Desafíos con NPM Audit Fix

Short description:

Al ejecutar la actualización de NPM y encontrar vulnerabilidades, el comando NPM audit fix puede no resolver los problemas. A pesar de múltiples intentos, las vulnerabilidades persisten.

Y simplemente te da una sugerencia. Así que vamos a intentarlo. Voy a poner eso en mi paquete JSON. Voy a hacer NPM update. Esto es lo que veo. NPM advierte, todos estos mensajes y demás. Y en la parte inferior, dice que tienes 15 vulnerabilidades. Pensé que tenía dos antes, ahora tengo 15. Y luego dice ejecuta NPM audit para detalles. Y estás como, hmm, está bien. ¿Adivina qué? Ya he hecho esto antes, voy a ejecutar NPM audit fix inmediatamente. Así que mucho y mucho código. Y si desplazo hacia abajo hasta el final, tengo que hacer eso en esa pantalla.

8. Desafíos con NPM Fix Force

Short description:

¿Por qué todavía tenemos 15 problemas incluso después de intentar NPM fix force? Es difícil averiguar qué hacer cuando no hay una respuesta fácil. Buscar en Google y Stack Overflow llevó al descubrimiento de una nueva característica de NPM que permite sobrescribir. Al actualizar el administrador de control de versiones de node, el archivo Docker y ejecutar pruebas, todo parecía estar bien. Sin embargo, la construcción de CI lanzó un error de SSL abierto, que fue ignorado.

Todavía tengo 15 vulnerabilidades. Entonces, ¿por qué? Esperaba que se hubieran ido. Así que vamos a hacer NPM fix force. No sé si eso es una etiqueta. Pero cuando eres un desarrollador, eso es lo que haces. Lo intentas de nuevo. Y todavía tenemos 15 problemas. No puedes superarlo.

Entonces, la parte difícil es realmente averiguar qué debería hacer. No hay una respuesta fácil. Tienes que parar, alejarte y pensar. ¿Verdad? Así que tenemos todas estas herramientas. Y saben sobre un hecho en un cierto rango de tiempo. Como, oh, 5.1.2. Pero no significa nada. No te ayuda a solucionarlo. Así que después de buscar en Google y Stack Overflow, oh, hay esta característica relativamente nueva de NPM. Puedes hacer una sobrescritura. Y puedes decir que no te importa qué versión se requiere en mi árbol de dependencias. Quiero esta. Así que déjame poner las últimas para estas. Así que, ya sabes, voy a actualizar mi administrador de control de versiones de node en mi máquina local, mi archivo Docker, todas estas cosas. De hecho, tengo algunas pruebas. Así que voy a hacer una comprobación previa al vuelo, que ejecuta todas ellas, y hacer un git push. Todo está en verde. Todo bien. Pero luego la construcción de CI dice, no, no va a funcionar. Y si te metes en el error, en realidad me está dando un error de SSL abierto. Así que estoy como, no, no quiero eso. Como,

9. Entendiendo Glob Parent y el problema de OpenSSL

Short description:

Y en realidad voy a revertir ese cambio. En todos mis pipelines, tiendo a tener continuar en caso de error. Azure Defender para Cloud Container Scanner encontró el mismo problema. Ahora, todas mis compilaciones están funcionando, pero eso no es el final de la historia. Necesito entender Glob Parent y el problema de OpenSSL. Esta vulnerabilidad es de tipo denegación de servicio, pero no sucederá en mi ejemplo. Estoy construyendo una aplicación de prueba de concepto que proporciona una evaluación. Es un CMS sin cabeza sin una base de datos, utilizando markdown para juntar todo. El árbol de archivos determina qué va a dónde. No hay entrada de usuario.

eso es aún peor, como la encriptación. Déjame simplemente ignorarlo. Y en realidad voy a revertir ese cambio. Y notarás que en el commit, también puse un enlace al hilo de Stack Overflow un poco, como, ¿por qué está ahí? Así que verás que en todos mis pipelines, tiendo a tener continuar en caso de error. Es como, gracias por la alerta, voy a seguir adelante. También hay un Azure Defender para Cloud Container Scanner. Y pasará por el code, y encontró exactamente lo mismo. Y entonces es como, está bien, déjame agradecerte por la alerta, necesito desactivarte también. Ahora, todas mis compilaciones están funcionando, ¿verdad? Pero eso no debería ser el final de la historia. Es solo que necesito desplegar. Entonces, sabes, continuar en caso de error, sé sobre el error, averigüemos qué vamos a hacer. La clave para eso es entender, ¿qué es Glob Parent? ¿Para qué lo estoy usando, verdad? ¿Y cuál es el problema de OpenSSL? ¿Y cómo va a ser usado? Entonces, sabes, estaba como, hmm, no estoy seguro sobre OpenSSL. Pero en realidad sí sé lo que Glob Parent va a hacer. Así que primero entendamos por qué, como, ¿qué tipo de vulnerabilidad es esta? Y es una denegación de servicio de algún tipo de vulnerabilidad, lo que básicamente significa que tu aplicación no está sirviendo solicitudes porque va a ser bombardeada. Y entonces hay una versión de red, pero también hay una, digamos, mala versión de code donde si le das las entradas correctas, entonces podría ralentizarse o incluso colapsar. ¿Verdad? ¿Va a suceder eso? ¿Como, en mi ejemplo? Entonces, no te mostré qué es este proyecto. Pero la respuesta es no. Entonces, estoy construyendo esta aplicación. Es una prueba de concepto. Y lo que quiero hacer es dar una especie de evaluación. Eso no es una lista de verificación. ¿Verdad? Entonces, si seleccionas ciertas opciones, entonces tal vez tu seguridad aumentará, pero a costa de un aumento de la complejidad. Y entonces, todas las cosas aquí, las preguntas y los factores, todo eso se hace en markdown. Entonces, está juntando todo esto. Es un CMS sin cabeza. No necesito una base de datos. Y está averiguando qué va a dónde y está adjunto a qué basado en el árbol de archivos. Entonces, eso es lo que está glopping. Está emparejando todas estas cosas. ¿Cómo tiro todo esto junto? Ese es mi sistema de archivos. ¿Verdad? No hay entrada de usuario.

10. Desafíos con Herramientas y el Menor de Dos Males

Short description:

Las herramientas no son el santo grial. Solo porque una herramienta identifica una vulnerabilidad no significa que debas dejar todo para abordarla. A veces se trata de elegir el menor de dos males. Por ejemplo, el problema de OpenSSL puede parecer arriesgado, pero el riesgo se considera aceptable en comparación con el impacto en el desarrollo. Es importante pasar por el proceso de evaluación de notificaciones y no solo confiar en métricas como alertas abiertas y vulnerabilidades.

Esta aplicación también tiene un proceso de construcción. Entonces, está haciendo todo eso en vivo, pero solo ejecutas una construcción en algún momento cuando terminas y cuando la despliegas, y estás ejecutándola en modo de producción o simplemente sirviéndola en modo estático o como se llame. Y ya no tienes eso. Esa brecha no está allí. Entonces, en este tipo de situación, lo que suelo decirle a la gente es que las herramientas son estúpidas. Solo estoy tratando de que recuerdes que la herramienta no es el santo grial. Solo porque dice que hay una vulnerabilidad, eso no significa, está bien, detén todo, deja todo lo que estás haciendo y, como, averigua eso. Porque incluso si averiguas eso, ¿verdad? podría ser, como en este caso, eligiendo el menor de dos males. Entonces, el problema de OpenSSL, lo que sea que tenga que ver con la encriptación que se usa para la cookie, donde los resultados, o más bien las entradas que tú diste, las respuestas que elegiste, se guardan, ¿verdad? y todo está encriptado. Pero para mí, he decidido que ese riesgo, aunque no hay datos de usuario reales en él, es peor, creo, que, está bien, algo que solo podría sucederme a mí en desarrollo. Entonces, no sabrás nada de eso hasta que pases por ese proceso. Y este fue solo un ejemplo particular que encontré este mes, ¿verdad? pero para cada tipo de notificación que recibes, tienes que pasar por este proceso. Y es realmente, realmente difícil. Y luego cuando de repente obtienes algo como esto, llegamos a ese otro punto de frustración, ¿verdad? cosas que están obstruidas. Algunas organizaciones medirán como, oh, cuántas alertas aún están abiertas, cuántas vulnerabilidades todavía están allí. Pero en realidad no te dice si es una seguridad, cuán malo, o como, dice alto o moderado, pero como, ¿es realmente tan malo? Como,

11. Artesanía y Versionado en DevOps

Short description:

Hacemos que DevOps sea realmente difícil, pero la clave es amar lo que haces y estar orgulloso de ello. Empezar con actualizaciones simples es un buen punto de partida. El versionado puede ser un desafío, especialmente con microservicios. La práctica y la disciplina son esenciales. Usar una herramienta como versión estándar y commits convencionales puede ayudar. Presta atención a los detalles y haz ajustes cuando sea necesario.

el menor de dos males. Eso es lo que siempre digo. Bueno. Entonces, ya sabes, hablamos de pull requests, ¿verdad? Hablamos de cómo necesitas confiar en tu equipo. También hablamos de que incluso con security, también tienes que confiar en tu equipo para aprender y crecer. Y la última cosa de la que quiero hablar hoy es realmente la artesanía. Porque hacemos que DevOps sea realmente difícil. Pero quiero que la gente realmente quiera hacerlo. Y la clave para eso, en mi opinión, es amar lo que estás haciendo. Y estar orgulloso de lo que haces. Entonces, esto es lo que veo mucho, ¿verdad? Como en todas partes. En GitHub open source también, no solo en el trabajo. Probablemente estás usando la interfaz de usuario de GitHub UI si haces clic en algo y dice actualizar, léeme, actualizar, léeme, actualizar, léeme. Eso está bien. Es un lugar para empezar. ¿Verdad? Ahora, lo interesante es cuando los clientes vienen a mí y uno de los mayores desafíos que la gente enfrenta es realmente el versionado, especialmente si están usando microservices. Y por alguna razón, tienes que correlacionar cosas. En cuyo caso no tienes un microservice. Tienes un monolito distribuido.

De todos modos, cuando ves algo como esto, parece super bonito y, como, oh, Dios mío, simple y super fácil. ¿Y cómo haces eso? Bueno, la respuesta es práctica y disciplina. Entonces, este es un registro de cambios que hice usando una herramienta llamada versión estándar y se basa en algo llamado commits convencionales. Y eso es lo que es. Es solo una convención de nombres. Entonces, cuando haces un mensaje de commit, así es como se ve. Cómo se da cuenta si hay una corrección de errores o una característica, es solo un prefijo. Ya sabes, lanza algunas cosas entre los paréntesis y tratará de categorizar las cosas para ti. Y luego también, si añades el hashtag y un número, por supuesto, GitHub lo enlaza con el problema. Ahora, si estás prestando mucha atención, puedes notar que algunos de esos también los he ajustado a mano. Porque incluso yo no soy perfecto. Incluso yo a veces estaré apurado y soy super meticuloso, por eso digo incluso yo. Estaré apurado y también enviaré

12. Proceso de Lanzamiento y Reconocimiento de Méritos

Short description:

Al hacer un lanzamiento, edito el registro de cambios para asegurar la comprensión del consumidor. Los errores durante el desarrollo son aceptables, pero los lanzamientos públicos deben lucir pulidos. Es importante asegurarse de que todos reciban crédito por su trabajo, tanto para el reconocimiento corporativo como para la apreciación del equipo.

algo. Pero cuando realmente hago un lanzamiento, reviso el registro de cambios y lo edito según sea necesario antes de confirmarlo. Porque en ese punto, lo estoy publicando para ti, el consumidor, y quiero que lo entiendas. Cualquier pequeño error que cometa en el medio, está bien. Es solo para mí. Pero en el punto en que digo, está bien, está listo para el público, quiero que se vea un poco más agradable. La otra cosa también, es que a veces somos como, no estás haciendo todo perfectamente. Y en este caso, tuvimos que reestructurar un montón de cosas. Da ese paso extra para asegurarte de que todos reciban crédito. Esto lo he visto suceder mucho en las empresas, donde desafortunadamente, la gente realmente cuenta esos commits. ¿Y conoces ese perfil de GitHub con todos esos pequeños cuadrados verdes? Entonces, necesitas asegurarte de que no solo para ti, sino también para tus colegas, ¿verdad?, que sus usuarios y nombres de usuario de GitHub también estén recibiendo crédito por ese trabajo. De lo contrario, la gente no lo ve. Ahora, tampoco se trata solo de ese tipo de trampa corporativa. También se trata de, digamos, apreciación de los equipos y gratitud por la ayuda que te están dando. Entonces, esto toma 30 segundos, pero va mucho más allá.

13. Invertir en Documentación y Personas

Short description:

Invierte tiempo en la documentación. Ayuda a entender el trabajo pasado. Las demostraciones pueden parecer bonitas, pero crear flujos de trabajo eficientes requiere años de experiencia. Comienza con buenos hábitos y pequeños pasos. La motivación es clave. Más contribuciones son mejores que ninguna. Invierte en personas. La documentación es una inversión. Piensa críticamente sobre las mejores prácticas. Sígueme en Twitter o YouTube.

realmente beneficia a la cultura de tu equipo. Otra cosa en la que quiero que la gente invierta tiempo es en hacer documentation, ¿verdad? Así que, escribo esto tanto para mí, como para las personas que van a usar el software que publico o las muestras, ¿verdad? No está destinado para humanos, lo siento, no está destinado para tus compilaciones. Está destinado completamente para humanos. Esto no tiene ningún propósito en code excepto para ayudarte a entender algo. Y eso es realmente, realmente importante porque casi siempre tenemos que volver y mirar cosas en el futuro. Y no recuerdo lo que hice la semana pasada, y mucho menos hace seis meses. Y si estamos trabajando en varios proyectos y microservices, etcétera, entonces, sí, a veces te tomas un largo descanso de un proyecto. Así que, es realmente importante agregar esa documentation. Ahora, cuando muestro demos en el trabajo, miras algo como esto, y esto es un flujo de trabajo de acción de GitHub. Y recientemente me tomé un tiempo para migrar completamente un flujo de trabajo de la tubería de Azure. Se ve muy bien, ¿verdad? Pero, ¿cuánto tiempo lleva? En realidad, años. Hay mucha experiencia que proviene de la creación de tuberías que funcionan bien para mí, no necesariamente para todos, ¿verdad? Y luego averiguar qué tipo de, está bien, hay una brecha aquí. Hay una brecha aquí. Esta característica funciona de esa manera. Lleva mucho tiempo. Cuanto más simple y elegante se ve, más esfuerzo se necesita para llegar allí. Y está bien. No empiezas allí, ¿verdad? Lo que quieres hacer es invertir en ti mismo, lo que significa buenos hábitos. Buenos hábitos, pequeños pasos que con el tiempo resultan en esa gran meta que estás tratando de alcanzar. Si intentas llegar a ella desde el primer día, lo que podrías terminar haciendo es en realidad dañando tu propia motivación y la motivación de tu equipo. Y eso es casi lo peor que puedes hacer, ¿verdad? Creo que es mejor tener más contribuciones y cosas que necesitas limpiar que no tener ninguna contribución. Y podrías pensar, oh, no, no, solo tienen que actualizar las solicitudes de extracción o lo que sea, ya sabes, solo tienen que hacer que la compilación se ponga verde. Pero hay un elemento humano en eso que podría faltar en ese tipo de reglas que son todo o nada, no hagas eso. Realmente, se trata de personas. Se trata de invertir en personas a largo plazo. Así que, cosas como documentation, etcétera, no es un costo, no es una tarea pendiente, no es una tarea, es una inversión. Y con eso, he terminado. Así que, gracias por venir a esta charla. Espero que te haga pensar críticamente la próxima vez que leas algún artículo sobre best practices, 10 cosas que debes hacer. ¿Realmente necesitas hacerlo? Y si estás interesado en más tipos de temas como este, contraintuitivo, ¿cómo es en realidad en la vida real? Puedes seguirme

QnA

Desplegando en Producción y Confianza vs Control

Short description:

La respuesta del público a la pregunta sobre el despliegue en producción fue sorprendente, siendo el control de pasaportes y la seguridad del aeropuerto la opción más elegida. Julie comparte su experiencia en Allianz, donde no había controles estrictos sobre los despliegues. La confianza es más importante que el control excesivo, especialmente para el crecimiento del equipo a largo plazo y la adición de valor empresarial. La mayoría de la audiencia está involucrada en la construcción de infraestructura en lugar de desplegar código orientado al usuario. Pasemos a la sesión de preguntas y respuestas.

en Twitter o en YouTube. Dan, muchas gracias. Es un placer tenerte aquí. Entonces, veamos los resultados. Entonces, la pregunta era, ¿cómo se siente desplegar en producción? Y con el 57%, tenemos un ganador en el control de pasaportes y la seguridad del aeropuerto seguido con el 27% saludando a tu entrenador mientras entras al campo o el 17% mostrando una identificación antes de entrar a un bar o club. ¿Es esto algo que esperabas, Julie? En realidad, me sorprendió. Los controles del aeropuerto que muchas personas. Pensé que esta audiencia, esta conferencia, gente que usa JavaScript, no sé, serían más relajados. Creo que lo que sorprende a algunas personas, porque mi trabajo hoy ayuda a los clientes de Azure es que incluso Allianz no tenía control de pasaportes y seguridad del aeropuerto. Así que tenemos todo, teníamos todos esos requisitos realmente super estrictos, ¿verdad? Entonces mi trabajo allí, era un ingeniero de pila completa y luego tuve un papel de mentor en muchos equipos y establecimos todas las reglas, pero llegó a un punto, por ejemplo, algunas de las cosas de cumplimiento, el dueño del producto. Así que una persona no técnica crearía las solicitudes de pull que podrían desplegar en producción, por ejemplo, o el dueño del producto sería el que haría clic en un botón en Jenkins que despliega. Como que no había controles duros en todo en ese momento. Es solo que, cuando tienes un negocio que vale tanto dinero, da miedo de todos modos. Como, solo vas a hacer clic en ese botón si estás cien por ciento seguro. Y porque las personas realmente poseen sus repositorios, poseen repositorios, en su mayoría es como, está bien, si la fastidio, solo me voy a disparar en la cara. Podría haber sido que fue muy temprano en el viaje a la cloud y no pusieron todas esas reglas todavía, pero no lo creo. Creo que fue solo que había una buena cantidad de confianza, lo cual es hilarante porque tengo seguridad del aeropuerto hoy en repositorios internos y ni siquiera trabajo en Azure, pero no es necesario, ¿verdad? Espero que quede claro desde el principio que no es necesario tener tanto control, la confianza es mucho más importante, creo, para el crecimiento a largo plazo del equipo, el espíritu del equipo, y luego también simplemente añadir más características y valor empresarial. Supongo que también con nuestra audiencia, la mayoría de las personas no están desplegando realmente code orientado al usuario, sino que están construyendo la infraestructura, ¿verdad? Entonces el chef no come en su propia cocina, pensando en eso, tienen miedo de su propio code tal vez. Pero bueno, nunca lo sabremos a menos que todos nos lo digan ahora en el chat. Así que, si estás listo para ello, pasemos a la sesión de preguntas y respuestas, y como recordatorio, si tienes alguna pregunta, aún puedes hacerlo en el canal DevOps Talk Q&A,

Manejo de Vulnerabilidades y Revisión del Éxito

Short description:

La primera pregunta es sobre cómo manejar un escenario en el que una vulnerabilidad de seguridad válida no puede ser solucionada debido a problemas de compatibilidad. Es importante encontrar un equilibrio y tomar una decisión basada en el nivel de riesgo y confianza. Revisar lo que se considera bueno y optimizar para el éxito debería ser un proceso continuo. Nunca se alcanza la perfección y a medida que se adquiere nueva experiencia y miembros del equipo, puede que sea necesario hacer cambios. La frecuencia de optimización depende de factores como la carga de trabajo y las prioridades. Es raro alcanzar la perfección, y si se hace, vale la pena cuestionar el estándar que se ha establecido. Mirar atrás a algo que construiste hace un año o dos y no sentir vergüenza indica una falta de progreso en el conocimiento.

así que asegúrate de unirte a eso. La primera pregunta es de Sissy Miller, ¿cómo manejarías el escenario en el que la vulnerabilidad es un problema válido para la aplicación pero no puede ser actualizada porque otras cosas no son compatibles con la solución? Entonces, si entendí correctamente, hay una vulnerabilidad de security válida, es decir, es una vulnerabilidad confirmada, no hay solución. ¿Y cómo deberíamos manejar eso, esa era la pregunta? Sí. Sí. Y también hay problemas de compatibilidad. Sí. Bueno, hay problemas de compatibilidad. Eso es algo que tienes que resolver con tu equipo de security. Y puedo decir que los clientes hacen esto, puedo decir que hace un par de años, estoy bastante seguro de que Allianz probablemente todavía hace esto. Tienes que encontrar ese equilibrio, ¿verdad? Y a menudo incluso en grandes organizaciones, tendrás básicamente un contrato, ¿de acuerdo? Va a estar bloqueado. Estás desplegando algo que tiene una vulnerabilidad conocida, y tienes sin embargo muchos días u horas para solucionarlo, y tienes que tomar esa decisión, ¿verdad? Hay una vulnerabilidad si el equipo o el dueño del negocio, el dueño del producto, dice, vamos de todos modos, está bien, entonces el reloj empieza a correr después de que entras en producción y lo solucionas para entonces y eso podría significar retroceder. Así que siempre va a haber un contrato, creo, entre todos los diferentes interesados en tu organización, y eso incluye al equipo de security. Y creo que lo más difícil es encontrar la cantidad correcta de confianza. El ejemplo que dije, es un problema válido de security, pero ¿cuál es la probabilidad de que ocurra? No existe tal cosa como 100% de security. Creo que simplemente tienes que evaluarlo, tomar un poco de riesgo, y averiguar qué es lo correcto para ti. Sí, estoy de acuerdo. La siguiente pregunta es de Jessica. ¿Con qué frecuencia deberíamos revisar qué es lo bueno? Tenemos que empezar en algún lugar, ¿y cómo sabemos con qué frecuencia deberíamos optimizar para el éxito? Creo que lo sabes en tu instinto. Así que nunca alcanzas la perfección. Y es gracioso porque muestro demos en el trabajo todo el tiempo y en masterclass. Y digo, oh, estamos haciendo esto ahora. Y luego como cinco meses después, lo haría totalmente diferente ahora. Y así como trabajas con lo que has construido o a medida que otras personas se unen a tu equipo, a medida que adquieres nueva experiencia, podrías cambiarlo. Y si tienes o no el tiempo para cambiarlo, eso va a depender de cuál es tu carga de trabajo, cuánto tiempo tienes, tienes que priorizar las características, etc. Así que probablemente vas a estar haciéndolo todo el tiempo y nunca alcanzarás la perfección. Y creo que si alcanzas la perfección, digo, eso es un estándar interesante. O tienes algo que, hay algunos servicios, lo despliegas y están terminados. Realmente no, como si no fuera un cliente que enfrenta, digamos que es una API para consumir, algunas cosas están terminadas y no las actualizas regularmente, tal vez para algún mantenimiento de security. Pero lo mismo entonces con automation, está terminado, así que. Sí, estoy pensando en, no sé de dónde obtuve esta sabiduría, pero una vez escuché, si estás mirando algo que construiste hace un año o dos años, y no te avergüenzas de ello, eso es algo malo, ¿verdad? Porque eso significa que no has progresado en tu conocimiento durante un año o dos años. Y mencionaste medio año, medio año es como aceptable, ¿verdad? Pero sí, si, y por supuesto no necesitas progresar si estás

Cambiando de Opinión y Adaptándose

Short description:

Cambiar de opinión no es algo malo. Significa que estás pensando como un científico, adaptándote a nueva información. Lo que funciona para mí puede que no funcione para ti, y eso está bien.

bien donde estás, entonces estás bien. Pero supongo que la mayoría de las personas aquí están aquí para aprender cosas nuevas. Y sí, pensé que era una buena regla general. Como si estás mirando algo de hace dos años, no te avergüenzas, es algo malo. Sí, no es solo vergüenza o lo que he estado aprendiendo, ¿verdad? Así que estoy leyendo este libro ahora mismo, se llama Piensa de Nuevo de Adam Grant. Así que a veces es solo que no es, aprendes algo nuevo, pero te das cuenta de algo y simplemente cambias de opinión y cambiar de opinión en realidad no es algo malo, ¿verdad? Significa que estás pensando como un científico, tal vez tienes nueva información ahora y cambias de opinión. No mejoró, es simplemente diferente. Y cuando lo cambié, funciona para mí, no funcionará para ti, pero eso está bien. Es para mí, no para ti.

Sobre-documentación y Encontrar el Equilibrio

Short description:

Definitivamente puedes sobre-documentar. Encontrar el equilibrio adecuado en la documentación es un desafío. Es importante escribir contenido conciso y al grano. Los puntos de bala pueden ser más efectivos que los párrafos largos. Es común que las personas eviten leer documentación extensa. El meme sobre perder tiempo en la documentación resuena con muchos. Es un desafío común que enfrentan las personas.

Eso es agradable. Tenemos otra pregunta de Cece Miller. ¿Es posible o puedes sobre-documentar y qué es demasiado, o es eso un asunto de equipo? Definitivamente puedes sobre-documentar, desearía poder compartir tantas cosas internas contigo. Documentation, es realmente difícil encontrar el equilibrio correcto y a veces hay como no mucho texto y en realidad eso lleva mucho más tiempo para averiguar qué es realmente necesario. Permíteme escribir un párrafo y eliminar el 10% o el 20% de él o reescribirlo porque no tiene sentido. Tanto como necesites, y no mucho más. Creo que una cosa que intento decirle a mis colegas y no tengo mucho éxito en ello es que no necesitas escribir un libro. No necesitas escribir párrafos enteros. Si puedes salirte con la tuya con puntos de bala, hazlo porque de todos modos nadie lo lee, ¿quién tiene tiempo para leer páginas? Así que decidirás o las personas con las que estás hablando decidirán si es demasiado. Un par de veces, oh, ¿no leíste la wiki? Y diré, no, es demasiado largo. Y soy los rects. Y entonces la gente dice, ¿no lo leíste? Yo digo, no, no lo leí. ¿No tuve tiempo para leer tanto texto? No. Sí. Me recuerda a un meme que estaba circulando hace unas semanas. Algo como, ¿por qué perder dos minutos leyendo una buena documentation cuando puedes pasar un día entero tratando de descubrir las cosas por ti mismo? Me gusta eso también, eso también funciona. Y me sentí personalmente atacado cuando lo leí. Nah, no es un ataque, está todo bien. Está todo bien. Pero supongo que muchas personas son culpables de eso. Tenemos un minuto. Así que vamos a hacer una pregunta rápida más de Sergio. Digamos que tienes algún proceso en el flujo de trabajo que se agregó por razones. ¿Cómo sabes cuándo es el momento de eliminar ese proceso porque ya no agrega valor? Oh, no creo que pueda hacer justicia a esa pregunta en menos de un minuto. Diría que vamos a la masterclass de esa persona, si puedes. Y luego lo responderé allí. Voy a darte una especie de sabrás cuando sepas. Pero para los detalles, vamos a la sala de chat espacial. Eso es un buen puente al siguiente paso. Porque este es todo el tiempo que tenemos para las preguntas y respuestas. Así que Julie va a ir a su chat espacial donde puedes continuar la conversación con Julie. Así que si quieres tener un tiempo uno a uno con Julie, puedes hacerlo ahora en el chat espacial. Julie, muchas gracias por unirte a nosotros. Ha sido un placer tenerte y disfruta el chat. Adiós. Adiós. Nos vemos más tarde.

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

Don't Solve Problems, Eliminate Them
React Advanced Conference 2021React Advanced Conference 2021
39 min
Don't Solve Problems, Eliminate Them
Top Content
Humans are natural problem solvers and we're good enough at it that we've survived over the centuries and become the dominant species of the planet. Because we're so good at it, we sometimes become problem seekers too–looking for problems we can solve. Those who most successfully accomplish their goals are the problem eliminators. Let's talk about the distinction between solving and eliminating problems with examples from inside and outside the coding world.
Using useEffect Effectively
React Advanced Conference 2022React Advanced Conference 2022
30 min
Using useEffect Effectively
Top Content
Can useEffect affect your codebase negatively? From fetching data to fighting with imperative APIs, side effects are one of the biggest sources of frustration in web app development. And let’s be honest, putting everything in useEffect hooks doesn’t help much. In this talk, we'll demystify the useEffect hook and get a better understanding of when (and when not) to use it, as well as discover how declarative effects can make effect management more maintainable in even the most complex React apps.
Design Systems: Walking the Line Between Flexibility and Consistency
React Advanced Conference 2021React Advanced Conference 2021
47 min
Design Systems: Walking the Line Between Flexibility and Consistency
Top Content
Design systems aim to bring consistency to a brand's design and make the UI development productive. Component libraries with well-thought API can make this a breeze. But, sometimes an API choice can accidentally overstep and slow the team down! There's a balance there... somewhere. Let's explore some of the problems and possible creative solutions.
React Concurrency, Explained
React Summit 2023React Summit 2023
23 min
React Concurrency, Explained
Top Content
React 18! Concurrent features! You might’ve already tried the new APIs like useTransition, or you might’ve just heard of them. But do you know how React 18 achieves the performance wins it brings with itself? In this talk, let’s peek under the hood of React 18’s performance features: - How React 18 lowers the time your page stays frozen (aka TBT) - What exactly happens in the main thread when you run useTransition() - What’s the catch with the improvements (there’s no free cake!), and why Vue.js and Preact straight refused to ship anything similar
Levelling up Monorepos with npm Workspaces
DevOps.js Conf 2022DevOps.js Conf 2022
33 min
Levelling up Monorepos with npm Workspaces
Top Content
Learn more about how to leverage the default features of npm workspaces to help you manage your monorepo project while also checking out some of the new npm cli features.
TypeScript and React: Secrets of a Happy Marriage
React Advanced Conference 2022React Advanced Conference 2022
21 min
TypeScript and React: Secrets of a Happy Marriage
Top Content
TypeScript and React are inseparable. What's the secret to their successful union? Quite a lot of surprisingly strange code. Learn why useRef always feels weird, how to wrangle generics in custom hooks, and how union types can transform your components.

Workshops on related topic

React Performance Debugging Masterclass
React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Top Content
Featured WorkshopFree
Ivan Akulov
Ivan Akulov
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
React Hooks Tips Only the Pros Know
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
Top Content
Featured Workshop
Maurice de Beijer
Maurice de Beijer
The addition of the hooks API to React was quite a major change. Before hooks most components had to be class based. Now, with hooks, these are often much simpler functional components. Hooks can be really simple to use. Almost deceptively simple. Because there are still plenty of ways you can mess up with hooks. And it often turns out there are many ways where you can improve your components a better understanding of how each React hook can be used.You will learn all about the pros and cons of the various hooks. You will learn when to use useState() versus useReducer(). We will look at using useContext() efficiently. You will see when to use useLayoutEffect() and when useEffect() is better.
React, TypeScript, and TDD
React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Top Content
Featured WorkshopFree
Paul Everitt
Paul Everitt
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.
Designing Effective Tests With React Testing Library
React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Top Content
Featured Workshop
Josh Justice
Josh Justice
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents- The different kinds of React application 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 DOM elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RTL tests and how to handle them
Prerequisites- Familiarity with building applications with React- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Testing Library- Machine setup: Node LTS, Yarn
Next.js 13: Data Fetching Strategies
React Day Berlin 2022React Day Berlin 2022
53 min
Next.js 13: Data Fetching Strategies
Top Content
WorkshopFree
Alice De Mauro
Alice De Mauro
- Introduction- Prerequisites for the workshop- Fetching strategies: fundamentals- Fetching strategies – hands-on: fetch API, cache (static VS dynamic), revalidate, suspense (parallel data fetching)- Test your build and serve it on Vercel- Future: Server components VS Client components- Workshop easter egg (unrelated to the topic, calling out accessibility)- Wrapping up
React at Scale with Nx
React Summit 2022React Summit 2022
160 min
React at Scale with Nx
WorkshopFree
Isaac Mann
Zack DeRose
2 authors
The larger a codebase grows, the more difficult it becomes to maintain. All the informal processes of a small team need to be systematized and supported with tooling as the team grows. Come learn how Nx allows developers to focus their attention more on application code and less on tooling.
We’ll build up a monorepo from scratch, creating a client app and server app that share an API type library. We’ll learn how Nx uses executors and generators to make the developer experience more consistent across projects. We’ll then make our own executors and generators for processes that are unique to our organization. We’ll also explore the growing ecosystem of plugins that allow for the smooth integration of frameworks and libraries.