1. Introducción a DevOps
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
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
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
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
¿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
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
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
¿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
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
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
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
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
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
Desplegando en Producción y Confianza vs Control
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
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
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
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.
React Summit 2023
Comments