Ajustando DevOps para las Personas sobre la Perfección

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

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.

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,

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

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.

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,

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é

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.