Ajustando DevOps para las personas por encima de 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 "de cero a héroe" deja a muchas personas persiguiendo la perfección y el FOMO. Esta sesión se centra 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 de operaciones y controles. Veamos la cantidad de ajustes y la afinación de todo como código, solicitudes de extracción, DevSecOps, monitoreo y más para priorizar el bienestar de los desarrolladores 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 y la disciplina manual pueden ser la clave para productos y experiencias excelentes.

33 min
25 Mar, 2022

Video Summary and Transcription

DevOps es un viaje que varía para cada empresa, y el trabajo remoto dificulta la transformación. Las solicitudes de extracción pueden ser frustrantes y lentas, pero historias de éxito como la empresa de Mateo Colia muestran los beneficios de implementar todos los días. Los desafíos con herramientas y vulnerabilidades requieren una consideración cuidadosa y una priorización. Invertir en documentación y personas es importante para flujos de trabajo eficientes y el crecimiento del equipo. La confianza es más importante que el control excesivo al implementar 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 es 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 quiero hacer algo un poco diferente. Quiero enfocarme más en las personas en lugar de, digamos, DevOps en teoría y en papel. Entonces, antes de comenzar, tengo que mostrar brevemente un descargo de responsabilidad de que estoy apareciendo aquí como yo misma y gran parte de lo que voy a compartir con ustedes hoy es mi opinión basada en mi experiencia. Además, no es una guía completa de DevOps para esta charla y la duración del tiempo. He decidido elegir un par de

2. Experiencia y Enfoque en DevOps

Short description:

He estado construyendo para la web durante mucho tiempo, trabajando en startups, empresas corporativas y como freelance. Me uní a Alianz Germany, 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 dificulta la transformación. Las mejores prácticas no son obligatorias. Se trata de las personas y el éxito en la entrega de un producto y el crecimiento de un equipo.

ejemplos para ilustrar los puntos que quiero destacar. Entonces, he estado construyendo para la web durante mucho tiempo. Un poco más antiguo de lo que parezco, y he trabajado en todo tipo de lugares, desde startups hasta empresas corporativas. Estuve trabajando por cuenta propia durante mucho tiempo, así que en realidad estaba trabajando como freelance en varias empresas y esa fue mi primera exposición a DevOps.

Luego me uní a Alianz Germany, que es una compañía de seguros multimillonaria, y trasladamos algunos proyectos a la nube en menos de un año. Fue un viaje loco, pero aprendí mucho no solo sobre DevOps, las habilidades, sino realmente a gran escala. Ya conocía muchas de esas prácticas y especialmente en Git y despliegues automatizados, pero transferir eso a todo el equipo es mucho más difícil de lo que parece. Hoy en día, soy ingeniero en Microsoft, parte del programa FastTrack para Azure, donde ayudo a los clientes a incorporarse a Azure. Me especializo en arquitectura en la nube y automatización de DevOps. No solo los ayudamos con las mejores prácticas guía. Si se encuentran con un gran problema o un desafío, también los ayudamos a desbloquearlo. Algunos de los contenidos aquí provendrán de esos escenarios de clientes, así como de internos de Microsoft, como mi historia, mi experiencia, por eso esta es mi opinión, no una especie de `así es como deberías hacerlo`. La razón es porque DevOps es un viaje. Cada empresa va a ser un poco diferente. Comienzan en lugares diferentes. Siempre tienes personas diferentes con diferentes preferencias y formas de trabajar. Entonces, 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 de 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. Entonces, algunas de las cosas de las que voy a hablar en términos de mejores prácticas se vuelven mucho más desafiantes cuando no tienes ese tiempo cara a cara para tener ese tipo de matices y es como, ¿está hablando en serio o simplemente está siendo sarcástica? Y luego algunas de esas reglas, especialmente con la seguridad, ¿cómo puedo flexibilizar algunas de ellas y por qué? Así que vamos a ver eso. Lo que quiero que saques de hoy son muchas de estas cosas que son mejores prácticas, incluso si te digo que lo son, pero no tienes que hacerlas. No tienes que hacerlas hoy. No tienes que hacerlas la próxima semana. Eventualmente tienes que llegar allí y también puedes llegar allí sin seguir algunas de esas mejores prácticas. Entonces no se trata de herramientas. Se trata de las personas. Y las personas marcarán la diferencia tanto en la entrega de un producto como en el crecimiento de un equipo, invertir en un equipo que estará contigo en un año o diez. 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 una buena práctica, pero también se puede hacer de manera incorrecta. Las solicitudes de extracción pueden ser frustrantes y lentas. Pueden crear un atasco de solicitudes de extracción. Una solicitud de extracción es como la seguridad del aeropuerto, diseñada para la comunidad de código abierto.

De acuerdo. Entonces, lo primero, las solicitudes de extracción. A todos les encantan las solicitudes de extracción, ¿verdad? Es una buena práctica. Pero también se puede hacer de manera incorrecta. Así que digamos que tenemos un flujo de trabajo de solicitudes de extracción. Todos están trabajando en una rama, ¿de acuerdo? Es posible que estés acostumbrado a abrir directamente la rama principal de nuevo, fusionar tu flujo de trabajo y hacer push, y será como: no, el servidor podría rechazar eso. Entonces tienes que abrir una solicitud de extracción y hacer tus confirmaciones, hacer todas estas cosas, y luego puedes tener una convención o flujo de trabajo configurado que diga: voy a poner el hashtag de aprobación. Un robot debería fusionar esto ahora. No funcionó. Permíteme hacerlo de nuevo. Permíteme es con lo que tengo que lidiar en el trabajo. A veces simplemente te rindes, ¿verdad? Y es posible que ni siquiera cierres 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á atascado. Ahora, incluso si las solicitudes de extracción se están realizando y las compilaciones se están ejecutando, eventualmente puedes fusionar el código. Pueden ser realmente lentas, y eso también es frustrante y decepcionante. Entonces, así es como podría verse una solicitud de extracción. En la documentación, suena muy fácil. Abrir, aprobar, cerrar y fusionar. Entonces, es posible que realmente esté vinculado a un pipeline y debas esperar a un agente de compilación. Si tienes muchas personas y no tienes suficientes agentes de compilación, no compraste los que realmente necesitas, esperarás para siempre. Entonces, si eres como yo, agarras tu teléfono y dices: déjame ver Twitter, ver qué está pasando. Regresas y cuando finalmente se ejecuta, oh, falló. Pero ya ha pasado media hora, una hora, déjame ir a almorzar, déjame volver. Eso tampoco es necesariamente muy productivo, ¿verdad? Entonces, lo que terminas teniendo es este atasco de solicitudes de extracción. Y eso tampoco es necesariamente útil. Me encanta este tweet de Keith donde habla sobre 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 porque una solicitud de extracción es como la seguridad del aeropuerto, ¿verdad? Cuando se introdujo por primera vez, estaba realmente diseñada más para la comunidad de código abierto y querías dar la bienvenida a contribuciones externas,

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 las personas se quedan atascadas. 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, existen historias de éxito como la empresa a la que Mateo Colia ayudó, que ahora implementa todos los días en lugar de cada dos semanas.

¿verdad? Grandes y pequeñas. Y quieres introducir una forma de colaborar en eso. No se trata solo de seguridad, ¿verdad? Se trata de discutir un tipo de cambio de código, oh, ¿a qué te refieres con esto, puedes hacer ese cambio? Pero si estás en el mismo equipo, ¿necesitas todas esas puertas? Tal vez no, ¿verdad? Entonces veamos cómo se ve realmente este flujo de trabajo y dónde se quedan atascadas las personas, ¿verdad? 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 veré a personas que la bloquean por completo, incluso los administradores no pueden hacer push directamente a ella. Así que realmente estás atrapado en este flujo de trabajo de solicitudes de extracción. El problema aquí es que todo esto se hace en código, ¿verdad? Y nadie es perfecto. Yo tampoco lo soy. Y a veces esas cosas se rompen por cualquier motivo. Y entonces lo que terminas teniendo es algo como esto. Así que borré todo lo que no se puede ver. Y tomé esta captura de pantalla esta mañana, y me puso muy 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 ahí porque Azure cambia todos los días. Hay errores ahí. La gente debería corregir errores tipográficos y enlaces rotos, etc. Pero lo que está sucediendo es que verás que tenemos alrededor de 50 solicitudes de extracción que están atascadas. Como este repositorio, en mi opinión, está fuera de control. Hay demasiadas. Y también puedes ver la cantidad de bifurcaciones que tenemos para un equipo que en realidad solo tiene 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, 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? Ahí es cuando las herramientas no te están ayudando. De hecho, te están perjudicando. Este es un gran tweet de Mateo Colia, quien está en el equipo principal de Node.js. Y realmente me encantó. Y hablaba de cómo ayudó a esta empresa, y antes implementaban cada dos semanas. Era una implementación nocturna. Muy larga. Y ahora lo hacen

5. Implementación diaria y los desafíos

Short description:

¿Cómo implementar todos los días? Elimina las barreras y confía en tu equipo. No siempre es simple. Las implementaciones en la vida real no siempre son perfectas. A veces se considera arriesgado implementar durante el horario laboral. Comienza con un cronograma de implementación menos frecuente y ajústalo según tus necesidades.

todos los días ahora. Entonces, ¿cómo? ¿Cómo lo harían todos los días? Y el punto clave es que eliminas esas barreras. Y confías en tu equipo, ¿verdad? Ellos pueden implementar cuando estén listos. Entonces eso suena muy simple, ¿verdad? Pero ¿es realmente tan simple? ¿Cómo se ve eso? Así que saqué esta foto realmente antigua de Allianz, ¿verdad? Entonces, ¿qué significa cuando estás listo para implementar? 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. Deploying During Business Hours and Gatekeeping

Short description:

Implementar durante el horario laboral puede considerarse arriesgado para aplicaciones internas. Comenzar con implementaciones 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, resaltando la necesidad de una consideración cuidadosa y priorización. Las alertas de Dependabot brindan asistencia automatizada para identificar problemas.

en startups, lo vi más en realidad en esta gran corporación. La gente decía que era demasiado arriesgado implementar durante el horario laboral para una aplicación interna de línea de negocio. Así que sigamos trabajando ocho horas, pero cambiemos todo y hagámoslo cuando nadie más lo esté usando. Y eso está bien al principio. Créeme, no es una meta. Creo que solo hicimos eso una vez con pizza y tengo que ocultar los rostros porque, sí, el GDPR. Así que realmente depende de los equipos. Al principio, no necesitas implementar 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. Otro ejemplo más complicado, especialmente cuando dices, ooh, 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. Veamos este ejemplo de cómo tal vez sea demasiado, o tal vez no reaccionemos ante ello. La semana pasada estaba dando, de hecho, un seminario web y estaba demostrando cómo usar seguridad y demás. Y nadie realmente dijo, Julie, pero mira eso. Hay una vulnerabilidad. ¿Por qué no lo estás mirando? Ojalá me lo hubieran preguntado a mí. Pero no lo hicieron. Así que vamos a verlo. Y te diré por qué todavía está ahí, y se quedará ahí por el momento. Entro en las alertas de Dependabot. Todo esto es automatizado. Oye, Julie, encontramos estos problemas. Deberías solucionarlos. Uno de ellos es realmente grave. Así que el último, 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ízalo y deberías estar bien.

7. Challenges with NPM Audit Fix

Short description:

Al ejecutar NPM update y encontrar vulnerabilidades, el comando NPM audit fix puede no resolver los problemas. A pesar de varios intentos, las vulnerabilidades persisten.

Y solo te da una sugerencia. Así que vamos a intentarlo. Voy a pegarlo en mi package 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 que ejecute NPM audit para obtener detalles. Y piensas, hmm, bien. Adivina qué. Ya he hecho esto antes, voy a ejecutar NPM audit fix de inmediato. Así que mucho, mucho código. Y si me desplazo hacia abajo, tengo que hacerlo en esa pantalla.

8. Challenges with NPM Fix Force

Short description:

¿Por qué todavía tenemos 15 problemas incluso después de intentar NPM fix force? Es difícil saber qué hacer cuando no hay una respuesta fácil. Buscar en Google y en Stack Overflow llevó al descubrimiento de una nueva función de NPM que permite realizar anulaciones. Al actualizar el gestor de versiones de nodo, el archivo Docker y ejecutar pruebas, todo parecía estar bien. Sin embargo, la compilación de CI arrojó un error de OpenSSL abierto, que fue ignorado.

Todavía tengo 15 vulnerabilidades. Entonces, como, ¿por qué? Esperaba que desapareciera. Así que hagamos 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 en realidad descubrir qué debo hacer. No hay una respuesta fácil. Debes detenerte, 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 eso no significa nada. No te ayuda a solucionarlo. Así que después de buscar en Google y en Stack Overflow, oh, hay esta función relativamente nueva de NPM. Puedes hacer una anulación. Y puedes decir que no te importa qué versión se requiere en mi árbol de dependencias. Quiero esta. Así que voy a poner las últimas para estas. Así que, ya sabes, voy a actualizar el gestor de versiones de nodo en mi máquina local, mi archivo Docker, todas estas cosas. En realidad, tengo algunas pruebas. Así que voy a hacer una verificación previa, que las ejecuta todas, y hacer un push en git. Todo está en verde. Todo bien. Pero luego la compilación de CI dice, no, no va a funcionar. Y si investigas el error, en realidad me está dando un error de OpenSSL abierto. Así que digo, no, no quiero eso. Como,

9. Understanding Glob Parent and the OpenSSL Issue

Short description:

Y en realidad voy a revertir ese cambio. En todas mis canalizaciones, tiendo a continuar en caso de error. Azure Defender for Cloud Container Scanner encontró el mismo problema. Ahora, todas mis compilaciones se están ejecutando, 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 ocurrirá 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, que utiliza markdown para unir todo. El árbol de archivos determina dónde va cada cosa. No hay entrada de usuario.

eso es aún peor, como encriptación. Permíteme simplemente ignorarlo. Y en realidad voy a revertir ese cambio. Y observa 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 todas mis canalizaciones, tiendo a 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 revisará el código, y encontró exactamente lo mismo. Y es como, está bien, gracias por la alerta, también necesito desactivarte. Ahora, todas mis compilaciones se están ejecutando, ¿verdad? Pero eso no debería ser el final de la historia. Solo necesito implementar. Entonces, ya sabes, continuar en caso de error, conozco el error, vamos a averiguar 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 se va a utilizar? Entonces, estaba pensando, hmm, no estoy seguro acerca de OpenSSL. Pero en realidad sí sé lo que Glob Parent va a hacer. Y así que primero entendamos por qué, como, ¿qué es esta especie de vulnerabilidad? Y es una vulnerabilidad de denegación de servicio, lo que básicamente significa que tu aplicación ya no está sirviendo solicitudes porque va a ser bombardeada. Y así hay una versión de red, pero también hay una, digamos, versión de código malo donde si le das las entradas correctas, podría ralentizarse o incluso bloquearse. ¿Va a suceder eso? Como, en mi ejemplo? Entonces, no te mostré qué es este proyecto. Pero la respuesta es no. Así que estoy construyendo esta aplicación. Es una prueba de concepto. Y lo que quiero hacer es dar una especie de evaluación. No es una lista de verificación. ¿Verdad? Entonces, si seleccionas ciertas opciones, tal vez tu seguridad aumente, pero a costa de un aumento de complejidad. Y así, todas las cosas aquí, las preguntas y los factores, todo eso se hace en markdown. Así que está uniendo todo esto. Es un CMS sin cabeza. No necesito una base de datos. Y está determinando dónde va cada cosa y a qué está adjunto según el árbol de archivos. Entonces, eso es lo que está agrupando. Está emparejando todas estas cosas. ¿Cómo lo junto todo? Ese es mi sistema de archivos. ¿Verdad? No hay entrada de usuario.

10. Challenges with Tools and Lesser of Two Evils

Short description:

Las herramientas no son la solución perfecta. Solo porque una herramienta identifique una vulnerabilidad no significa que debas dejar todo para solucionarla. A veces se trata de elegir el mal menor. 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 evaluar las notificaciones y no depender únicamente de métricas como alertas abiertas y vulnerabilidades.

Esta aplicación también tiene un proceso de compilación. Entonces, está haciendo todo eso en vivo, pero solo ejecutas una compilación en algún momento cuando hayas terminado y cuando la implementas, y la estás ejecutando en modo de producción o simplemente sirviéndola en modo estático o como se llame. Y ya no tienes eso. Esa brecha ya no existe. Entonces, en este tipo de situación, lo que les digo a las personas es que las herramientas son estúpidas. Solo trato de hacerles recordar que la herramienta no es la solución perfecta. Solo porque diga que hay una vulnerabilidad, eso no significa que debas detener todo, abandonar todo lo que estás haciendo y, como, solucionarlo. Porque incluso si lo solucionas, ¿verdad?, podría ser, como en este caso, elegir el mal menor. Entonces, el problema de OpenSSL, lo que tiene que ver con la encriptación que se utiliza para la cookie, donde se guardan los resultados o las respuestas que diste, está todo encriptado. Pero para mí, he decidido que el riesgo, aunque no haya datos de usuario reales ahí, es peor, creo, que algo que solo podría sucederme 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, debes pasar por este proceso. Y es realmente, realmente difícil. Y luego, cuando de repente te encuentras con algo como esto, llegamos a ese otro punto de frustración, ¿verdad?, cosas que están bloqueadas. Algunas organizaciones medirán, oh, cuántas alertas siguen abiertas, cuántas vulnerabilidades siguen ahí. Pero en realidad no te dice si es una security, qué tan malo o, como, dice alto o moderado, pero, ¿es realmente tan malo? Como,

11. Craftsmanship and Versioning in DevOps

Short description:

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

el mal menor. Eso es lo que siempre digo. Bien. Entonces, ya sabes, hablamos de solicitudes de extracción, ¿verdad? Hablamos de cómo debes confiar en tu equipo. También hablamos de cómo, incluso con la seguridad, también debes confiar en tu equipo para aprender y crecer. Y lo último de lo que quiero hablar hoy es en realidad la artesanía. Porque hacemos que DevOps sea realmente difícil. Pero quiero que las personas realmente quieran 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, también en código abierto, no solo en el trabajo. Probablemente estés usando la interfaz de usuario de GitHub si estás haciendo clic en algo y dice `actualizar, leerme, actualizar, leerme, actualizar, leerme`. Eso está bien. Es un buen punto de partida. ¿Verdad? Ahora, lo interesante es cuando los clientes vienen a mí y uno de los mayores desafíos que enfrentan las personas es en realidad la versión, especialmente si están utilizando microservicios. Y por alguna razón, tienes que correlacionar las cosas. En ese caso, no tienes un microservicio. Tienes un monolito distribuido.

De todos modos, cuando ves algo como esto, se ve súper agradable y, como, oh, Dios mío, simple y súper fácil. ¿Y cómo lo haces? Bueno, la respuesta es práctica y disciplina. Entonces, este es un registro de cambios que hice usando una herramienta llamada standard version y se basa en algo llamado commits convencionales. Y eso es lo que es. Es solo una convención de nomenclatura. Entonces, cuando haces un mensaje de commit, así es como se ve. Cómo determina si es una corrección de errores o una nueva función, es solo un prefijo. Sabes, agregas algunas cosas entre paréntesis y tratará de categorizar las cosas por ti. Y también, si agregas el hashtag y un número, por supuesto, GitHub lo vincula con el problema. Ahora, si prestas mucha, mucha atención, puedes darte cuenta de que algunos de esos también los ajusté manualmente. Porque incluso yo no soy perfecto. Incluso yo a veces tengo prisa y soy súper meticuloso, por eso digo incluso yo. Tendré prisa y también enviaré

12. Proceso de lanzamiento y dar crédito

Short description:

Cuando hago un lanzamiento, edito el registro de cambios para garantizar 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 comprometerlo. Porque en ese momento, lo estoy publicando para ti, el consumidor, y quiero que lo entiendas. Cualquier pequeño error que cometa en el proceso, está bien. Es solo para mí. Pero en el momento en que digo: `ok, está listo para el público`, quiero que luzca un poco mejor. Lo otro también es que a veces estamos como, no estás haciendo todo perfectamente. Y en este caso, tuvimos que reestructurar muchas cosas. Da ese paso adicional para asegurarte de que todos reciban crédito. Esto lo he visto suceder mucho en el ámbito corporativo, donde desafortunadamente, las personas realmente cuentan esos commits. ¿Y conoces ese perfil de GitHub con todos esos pequeños cuadros verdes? Entonces, debes asegurarte de que no solo tú, sino también tus colegas, ¿verdad?, que sus usuarios y nombres de usuario de GitHub también reciban crédito por ese trabajo. De lo contrario, la gente no lo ve. Ahora, no se trata solo de ese tipo de vacío corporativo. También se trata de, digamos, apreciar a los equipos y estar agradecido por la ayuda que te brindan. Entonces, esto lleva 30 segundos, pero es importante.

13. Invertir en Documentación y Personas

Short description:

Invierte tiempo en documentación. Ayuda a comprender el trabajo pasado. Las demostraciones pueden lucir bien, 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 largo para la cultura de tu equipo. Otra cosa en la que quiero que las personas inviertan tiempo es en hacer documentación, ¿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 a las máquinas, lo siento, está destinado completamente a los humanos. No tiene ningún propósito en el código excepto ayudarte a entender algo. Y eso es realmente, realmente importante porque casi siempre tenemos que volver atrás 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 microservicios, etc., entonces, sí, a veces tomamos un largo descanso de un proyecto. Así que, es realmente importante agregar esa documentación. Ahora, cuando muestro demostraciones en el trabajo, mira 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 canalización de Azure. Se ve realmente bien, ¿verdad? Pero, ¿cuánto tiempo lleva? En realidad, años. Hay tanta experiencia que proviene de simplemente crear canalizaciones que funcionen bien para mí, no necesariamente para todos, ¿verdad? Y luego descubrir un tipo de, okay, aquí hay una brecha. Aquí hay una brecha. Esta función funciona de esta manera. Lleva mucho tiempo. Cuanto más simple y elegante se vea, más esfuerzo se necesita para llegar allí. Y está bien. No comienzas ahí, ¿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 ese gran objetivo que estás tratando de alcanzar. Si intentas llegar allí desde el primer día, lo que podrías terminar haciendo es perjudicar 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 contribuciones. 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 en verde. Pero hay un elemento humano en eso que podría faltar en ese tipo de reglas que son todo o nada, no lo hagas. Realmente se trata de las personas. Se trata de invertir en las personas a largo plazo. Entonces, cosas como la documentación, etc., no es un costo, no es una tarea, no es una obligación, 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 mejores prácticas, 10 cosas que debes hacer. ¿Realmente necesitas hacerlo? Y si estás interesado en más tipos de temas como este, contraintuitivos, ¿cómo es realmente en la vida real? Puedes seguirme

QnA

Despliegue 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, con el control de pasaportes y la seguridad del aeropuerto como la opción principal. Julie comparte su experiencia en Allianz, donde no había controles estrictos en los despliegues. La confianza es más importante que el control excesivo, especialmente para el crecimiento a largo plazo del equipo y para agregar valor comercial. La mayoría del público está involucrado en la construcción de infraestructura en lugar de desplegar código orientado al usuario. Pasemos a la sesión de preguntas y respuestas.

Sígueme en Twitter o en YouTube. Dan, muchas gracias. Es bueno tenerte aquí. Entonces, veamos los resultados. La pregunta fue, ¿cómo se siente desplegar en producción? Y con un 57%, tenemos un ganador en el control de pasaportes y la seguridad del aeropuerto, seguido de un 27% saludando a tu entrenador mientras entras al campo o un 17% mostrando una identificación antes de entrar a un bar o club. ¿Esto es algo que esperabas, Julie? En realidad, me sorprendió. Los controles de aeropuerto afectan a mucha gente. Pensé que este público, esta conferencia, personas que usan 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 teníamos todas esas exigencias realmente estrictas, ¿verdad? Entonces, mi trabajo allí, era un ingeniero full stack y luego tuve un rol de mentoría en muchos equipos y establecimos todas las reglas, pero llegó un punto en el que, por ejemplo, algunas cosas de cumplimiento, el propietario del producto. Una persona no técnica crearía las solicitudes de extracción que podrían desplegar en producción, por ejemplo, o el propietario del producto sería quien hiciera clic en un botón en Jenkins para desplegar. No había controles estrictos en todo en ese momento. Es solo que cuando tienes un negocio que vale tanto dinero, de todos modos da miedo. Entonces, solo vas a hacer clic en ese botón si estás cien por ciento seguro. Y porque las personas realmente son dueñas de sus repositorios, son dueñas de los repositorios, en su mayor parte es como, bueno, si meto la pata, me dispararé en la cara. Puede ser que fuera muy temprano en el viaje a la nube y aún no habían establecido todas esas reglas, pero no creo que sea así. Creo que simplemente había una buena cantidad de confianza, lo cual es gracioso porque hoy en día tengo seguridad de aeropuerto 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 de equipo y también para agregar más características y valor comercial. Supongo que también con nuestra audiencia, la mayoría de las personas no están desplegando código orientado al usuario, sino que están construyendo la infraestructura, ¿verdad? El chef no come en su propia cocina, pensando en eso, tal vez tienen miedo de su propio código. Pero bueno, nunca lo sabremos a menos que todos nos lo digan ahora en el chat. Así que, si estás listo, pasemos a las preguntas y respuestas, y como recordatorio, si tienes alguna pregunta, aún puedes hacerla en el canal de preguntas y respuestas de DevOps.

Manejo de Vulnerabilidades y Revisando el Éxito

Short description:

La primera pregunta trata sobre cómo manejar un escenario en el que una vulnerabilidad de seguridad válida no se puede solucionar 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 es bueno y optimizar para el éxito debe ser un proceso continuo. Nunca se alcanza la perfección y a medida que se adquiere nueva experiencia y se incorporan nuevos miembros al equipo, es posible que sea necesario realizar 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 logra, vale la pena cuestionar el estándar establecido. Mirar hacia atrás algo que construiste hace uno o dos años 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 donde la vulnerabilidad es un problema válido para la aplicación pero no se puede actualizar porque otras cosas no son compatibles con la solución? Entonces, si entendí correctamente, hay una vulnerabilidad de seguridad válida, es decir, una vulnerabilidad confirmada, pero no hay solución. ¿Y cómo deberíamos manejar eso, esa fue la pregunta? Sí, sí. Y también hay problemas de compatibilidad. Sí, eso es algo que debes 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 todavía lo hace. Tienes que encontrar ese equilibrio, ¿verdad? Y a menudo, incluso en organizaciones grandes, tendrás básicamente un contrato, ¿de acuerdo? Va a estar bloqueado. Estás implementando algo que tiene una vulnerabilidad conocida, y tienes tantos días u horas para solucionarlo, y tienes que tomar esa decisión, ¿verdad? Hay una vulnerabilidad si el equipo o el propietario del negocio, el propietario del producto dice, seguimos adelante, de acuerdo, entonces el reloj comienza a correr después de que entras en producción y lo solucionas para entonces, y eso podría significar retroceder. Siempre habrá 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 adecuada de confianza. El ejemplo que mencioné, es un problema de seguridad válido, pero ¿cuál es la probabilidad de que ocurra? No existe tal cosa como una seguridad del 100%. Creo que simplemente tienes que evaluarlo, correr un poco de riesgo, y descubrir qué es lo correcto para ti. Sí, estoy de acuerdo. La siguiente pregunta es de Jessica. ¿Con qué frecuencia deberíamos revisar lo que es bueno? Tenemos que comenzar en algún lugar, y ¿cómo sabemos con qué frecuencia debemos optimizar para el éxito? Creo que lo sabes en tu instinto. Nunca se alcanza la perfección. Y es gracioso porque muestro demostraciones en el trabajo todo el tiempo y en seminarios web. Y digo, oh, ahora estamos haciendo esto. Y luego, como cinco meses después, lo haría de manera completamente diferente. Y a medida que trabajas con lo que has construido o a medida que otras personas se unen a tu equipo, a medida que adquieres nueva experiencia, es posible que lo cambies. Y si tienes tiempo para cambiarlo o no, eso dependerá de tu carga de trabajo, cuánto tiempo tienes, si tienes que priorizar características, etc. Probablemente lo estarás haciendo todo el tiempo y nunca alcanzarás la perfección. Y creo que si alcanzas la perfección, pienso, eso es interesante. O tienes algo que, hay algunos servicios, los implementas y ya está. Realmente no necesitas, si no es para el cliente, digamos que es una API para consumir, algunas cosas están terminadas y no las actualizas regularmente, tal vez solo para el mantenimiento de security. Pero lo mismo ocurre con la automation, está más o menos terminado, así que. Sí, estoy pensando, no sé de dónde saqué esta sabiduría, pero una vez escuché que si miras algo que construiste hace un año o dos años, y no te avergüenzas de ello, eso es 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 aceptable, ¿verdad? Pero sí, si, 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 y no te avergüenzas, eso es malo. Sí, no solo avergonzado o lo que he estado aprendiendo, ¿verdad? Así que estoy leyendo este libro ahora, se llama Piensa de Nuevo por Adam Grant. A veces es simplemente que no, aprendes algo nuevo, pero te das cuenta de algo y simplemente cambias de opinión y cambiar de opinión no es algo malo, ¿verdad? Significa que estás pensando como un científico, tal vez ahora tienes nueva información de aprendizaje y cambias de opinión. No mejoró, simplemente es diferente. Y cuando lo cambié, funciona para mí, no funcionará para ti, pero está bien. Es para mí, no para ti.

Sobre-documentación y Encontrar Equilibrio

Short description:

Definitivamente se puede sobre-documentar. Encontrar el equilibrio adecuado en la documentación es un desafío. Es importante escribir contenido conciso y directo al punto. Los puntos clave pueden ser más efectivos que párrafos extensos. 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 bueno. Tenemos otra pregunta de Cece Miller. ¿Es posible o se puede sobre-documentar y qué es demasiado, o es algo del equipo? Definitivamente se puede sobre-documentar, desearía poder compartir tantas cosas internas contigo. Documentación, es realmente difícil encontrar ese equilibrio adecuado y a veces hay como no mucho texto y en realidad eso lleva mucho más tiempo para descubrir qué es realmente necesario. Permíteme escribir un párrafo y eliminar como 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 decirles a mis colegas y no tengo mucho éxito es que no necesitas escribir un libro. No necesitas escribir párrafos completos. Si puedes usar viñetas, hazlo porque de todos modos nadie lo lee, ¿quién tiene tiempo para leer páginas? Así que tú decidirás o las personas con las que estás hablando decidirán si es demasiado. Las pocas veces, oh, ¿no leíste el wiki? Y yo diré, no, es demasiado largo. Y soy el rects. Y la gente dice, ¿no lo leíste? Y 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 documentación 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 sentí que me atacaban personalmente cuando leí eso. Nah, no es un ataque, está todo bien. Está todo bien. Pero supongo que mucha gente es culpable 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 responder esa pregunta en menos de un minuto. Diría que vayamos al chat espacial con esa persona, si puedes. Y luego la responderé allí. Te voy a dar una especie de sabrás cuando lo sepas. Pero para más detalles, vayamos a la sala de chat espacial. Eso es un buen puente hacia el 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 a solas con Julie, ahora puedes hacerlo en el chat espacial. Julie, muchas gracias por unirte a nosotros. Ha sido un placer tenerte y disfruta del chat. Adiós. Adiós. Nos vemos luego.

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 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.
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.
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 Summit 2023React Summit 2023
23 min
React Concurrency, Explained
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

Workshops on related topic

React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Featured WorkshopFree
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 Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
Top Content
Featured Workshop
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 Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Top Content
Featured WorkshopFree
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.
React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Featured Workshop
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
React Day Berlin 2022React Day Berlin 2022
53 min
Next.js 13: Data Fetching Strategies
Top Content
WorkshopFree
- 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 Summit 2022React Summit 2022
160 min
React at Scale with Nx
WorkshopFree
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.