Infra vs Apps: ¿Dónde están mis Pipelines?

Hola, mi nombre es Julie. Soy ingeniera en Microsoft y hoy voy a hablarles sobre CICD y cómo funciona todo, y cómo funciona cuando tienes aplicaciones e infraestructura.

Así que un poco sobre mí. Como dije, soy ingeniera en Microsoft. Formo parte del programa Fast Track para Azure, lo que significa que ayudo a incorporar a los clientes a Azure. Antes de eso, fui Arquitecta Empresarial en Allianz Alemania, que es una compañía de seguros multimillonaria, y en realidad muchas de las opiniones y recomendaciones que les voy a dar hoy provienen de esa experiencia, así como de mi experiencia en Microsoft. Antes de eso, fui ingeniera full-stack, y todavía lo soy, y diseñadora.

Así que vengo del mundo Mac, de código abierto. Me gusta Node.js, Ruby, realmente no me gusta Windows. Soy una persona muy opinativa, así que trataré de mencionar cuando algo es mi opinión personal y recomendación. La foto que puse aquí es nostálgica porque fue literalmente la última semana de febrero antes del confinamiento debido a la Corona. Así que se siente muy extraño no solo trabajar de forma remota sin haber conocido nunca a tus colegas, sino también dar una charla en este momento a través de video. Pero parece funcionar.

De acuerdo, comencemos con un ejemplo muy simple. Hoy les voy a presentar varios casos de uso. Voy a intentar empezar de forma sencilla, y luego se vuelve realmente complicado muy rápidamente, pero la idea es enseñarles a pescar, y no darles un pez, cuando se trata de descubrir CICD por ustedes mismos.

Así que empecemos con lo más fácil posible, ¿verdad? Un mono repositorio, porque venimos de los monolitos. Muy simple. Voy a hacer un push y un servidor de compilación lo recogerá. Así que aquí tengo Jenkins. Jenkins es mi servidor de compilación favorito de todos los tiempos. Sí, también uso Azure DevOps y GitHub Actions, pero aún prefiero Jenkins.

De todos modos, digamos que hago un push a la rama principal. Se implementará en mi entorno de producción. Digamos que eventualmente estoy satisfecho. De alguna manera, en mi computadora local, hago cambios sin piedad en producción, y luego hago push de los cambios a producción y Jenkins los implementa en mi entorno de producción. Todo está bien, creo. ¿Cómo sabes que realmente funciona? Sabes, como ese tipo de CI que simplemente va allí. Hace algunas tareas. Pero ¿realmente funciona? ¿Cómo llegas al punto de la entrega continua? ¿Puedes hacer promoción automatizada? Eso es un poco más complicado de lo que muchas personas esperan cuando lo hacen por primera vez.

Entonces, todavía tenemos el mismo mono repositorio, la misma especie de aplicación monolítica. Vamos a hacer un push a nuestra rama principal, que recuerden, corresponde a nuestro entorno de desarrollo. Jenkins lo habrá implementado. Todo está listo. Ejecutemos algunas pruebas de extremo a extremo. Así que en este ejemplo teórico, digamos que tengo una aplicación de una sola página que en realidad tiene un conjunto de pruebas de extremo a extremo, que abrirá un navegador, hará clic en todo. Y lo que mi usuario final intenta hacer en la aplicación, podemos verificar que funcione como se espera. Así que tal vez pueda comprar una camiseta, por ejemplo. Según los resultados de esa prueba, si no funcionan, entonces decimos, oh, falló, fin del trabajo, fin de la historia, fin del trabajo de compilación, eso es. Digamos que realmente funciona. Lo que puedes hacer es hacer que Jenkins haga ese commit por ti en esa rama de producción. Mientras antes, tal vez hayas hecho clic en todo manualmente para asegurarte de que funcione, ahora puedes ejecutar un conjunto de pruebas de extremo a extremo y decir, okay, tengo confianza, implementémoslo en producción, lo que iniciará otro trabajo, y luego lo implementaremos en producción.

Suena muy simple en la práctica, ¿verdad? Pero en realidad es mucho más desafiante de lo que esperarías. Por lo tanto, es realmente, realmente difícil escribir pruebas en general, y luego escribir pruebas de extremo a extremo, y luego para las personas que tienen cosas como el procesamiento de tarjetas de crédito, etc., que tienen que hacer, realmente complicado. Y está bien si no los tienes, y está bien incluso si los tienes, aún no haces promoción automática. Así que la mayoría de las veces no hago promoción automática, por ejemplo, pero eso se debe principalmente a que no programo todos los días, solo algunos días.

De todos modos, hagámoslo un poco más complicado. Digamos que has estado trabajando en tu aplicación durante un par de años, y quieres separar las cosas, porque tenemos dispositivos móviles, así que vas a separar tu backend. Ahora hacemos un cambio en la rama principal. Jenkins va a decir, bueno, ¿qué quieres que haga? ¿Debo implementar el backend, el frontend o ambos? De repente, es súper confuso, pero ¿cómo encajas todo? Y luego uno de los mayores desafíos cuando haces CI-CD, y especialmente cuando estás en esa fase en la que no estás acostumbrado a tener múltiples componentes implementables. Tienes tantos eventos y disparadores, y bueno, Jenkins va a ejecutar un trabajo, pero ¿con qué código, por qué? Y usualmente las personas, ya sabes, hacen un seguimiento de los push, qué rama se activó, qué archivos cambiaron. Entonces, anteriormente viste que había una subcarpeta para el frontend, y había otra subcarpeta para el backend. Hay otros disparadores que la gente olvida, como las solicitudes de extracción. Una forma muy fácil de hackear a alguien, por cierto, porque si la solicitud de extracción realmente hace una implementación, entonces tal vez pueda bifurcar el repositorio y hacer una solicitud de extracción y, ja, estoy en tu entorno. Pero soy así de desagradable porque solía ser un arquitecto empresarial, y solo encontraba agujeros en el software de las personas. Y en términos de eventos que pueden desencadenar cosas, ¿verdad?, porque quieres automatizar según lo que ves a la derecha aquí, una lista de eventos de webhook para las acciones de GitHub. Ves las solicitudes de extracción, ves la revisión, solo un comentario en la solicitud de extracción, lo cual también tiene sentido. Tal vez quieras decir, eh, Julie, eh, Julie, tienes que mirar esto. Debido a que tenemos tantas posibilidades, es realmente aterrador la cantidad de cosas que tenemos que hacer un seguimiento. Y una vez que lo hayas resuelto en tu cabeza, aún tienes que ponerlo en tu pipeline, lo cual es, suena fácil, pero no necesariamente lo es. Porque si miras aquí, tengo dos ejemplos. Entonces, el primero es bastante simple, ¿verdad? Es un código Gruby para un archivo Jenkins, y parece código. Dice cuando, hay corchetes. Bien, estoy bastante seguro de lo que va a suceder. Cuando tienes YAML, ¿verdad?, que es cierto para muchas plataformas de CI, incluyendo Azure DevOps y GitHub Actions, es fácil olvidar algo. La indentación está mal. A veces tienes pistas, pero espera, quiero excluir, porque hay algún archivo ahí que realmente no debería desencadenar una implementación. Es un archivo readme, etc. Y de repente están sucediendo cosas, y también significa que todo se ralentiza, ¿verdad? Tienes todos estos trabajos esperando para ejecutarse, o sí, simplemente estás pasando tiempo tratando de averiguar por qué algo está sucediendo cuando no quieres que suceda. Y luego, recuerda que dijimos que ahora tenemos backend y frontend, y luego tienes desarrollo y producción. De repente tienes cuatro. Y tienes este gran archivo aquí, como ejemplo.

Cuando se trata del frontend en desarrollo, haz esto. Cuando se trata del frontend en producción, haz esto. Puede que solo sea la parte de 'cuando', está bien, cambiemos algunas variables de configuración. Pero el punto es que tienes cuatro casos diferentes de los que preocuparte. Así que se vuelve un poco confuso, ¿qué está cambiando y por qué? Personalmente, me gusta separarlos en diferentes archivos. El servidor de compilación a menudo muestra 'el pipeline de desarrollo frontend se está ejecutando' o 'el pipeline de producción backend se está ejecutando'. Es más fácil de ver, mientras que antes solo podías ver que se estaba implementando. Bueno, ¿qué se está implementando? Eso es realmente difícil de entender.

A muchas personas no les gusta esto porque son demasiados archivos y, oh, sabes, no estás reutilizando código en una biblioteca, etc. No me importa. He estado trabajando en la web durante, wow, 20 años. No, no, no, 15, 15 años como empleado. Y lo más importante en realidad es cuánto tiempo te lleva debuggear algo. ¿Cuánto tiempo te lleva arreglar algo cuando algo está roto en producción porque eso te cuesta dinero. Sí, hacer que el código sea pequeñas bibliotecas agradables es divertido. También disfruto haciendo eso. Pero lo más importante en términos de prioridad es poder arreglar cosas y construir cosas súper rápido. De acuerdo.

Lo siguiente que es complicado, ahora que hemos dividido las cosas, ¿verdad?, es que también estamos implementando de manera diferente. Tenemos que averiguar, oh, desde la perspectiva del usuario, ya no puedo comprar una camiseta por alguna razón. Y para rastrear eso, vamos a ver las versiones. Y luego tienes diferentes versiones para el frontend y el backend. Pero ¿qué significa eso para tu aplicación en general?

Sin embargo, si te estás haciendo esa pregunta, es porque realmente no tienes los servicios independientes. Pensabas que estabas construyendo microservicios, pero en realidad lo que tienes es un monolito distribuido. Así que supongamos que has descubierto eso ahora, has aprendido un poco, y vas a seguir adelante. Ahora vas a hacer microservicios.

De acuerdo, he elegido el ejemplo más simple posible para un microservicio. Todos saben qué es una calculadora. Digamos que ahora solo estoy construyendo el frontend. El resto de los servicios, ellos hacen algo. Yo hablo con la API. Realmente no me importa. Muy fácil para mí. Solo versiono algo. Ahora mismo los backends son estables, ¿verdad?, porque asumo que hacen lo que tienen que hacer. Funciona. Pero lo realmente importante de entender es que si algo es estable o no, no es un problema tecnológico. Será un problema de las personas. Para ilustrar eso, digamos que las personas que están trabajando en Multiplicar. Van a hacer algo extraño, ¿verdad?. Así que hacen un cambio y se implementa en su entorno de desarrollo. Pero no saben si algo se rompió, ¿verdad?, para el usuario que quiere comprar una camiseta. Entonces, lo que pueden hacer en su pipeline es tomar esas pruebas de la aplicación frontend y ejecutarlas. Pero ¿contra qué versión las estás ejecutando? Eso también es algo difícil de averiguar. Y una vez que tienes esa prueba, puedes averiguar, ¿ok, muevo ese cambio hasta el final o no lo hago? La cuestión es que estás buscando esa certeza, que puedes tener o no. Y en última instancia, en mi experiencia, lo que determina si necesitas pruebas de extremo a extremo y si confías al 100% en ellas es la estabilidad de tu producto, ¿verdad? Una calculadora es muy simple, ¿verdad? Simplemente... uno más uno es igual a dos. Cuando se trata de seguros, es un poco más complicado.

E incluso si la tecnología no necesariamente hace lo que esperas que haga, si las reglas del negocio son muy claras, es un poco más fácil resolver las cosas. De todos modos, lo más importante es entender que debes hablar entre nosotros. Así es como resolvemos las cosas. Incluso si no tienes esas pruebas de extremo a extremo, o incluso si las tienes, ve al Chat, habla con la gente.

Bien, hagamos esto un poco más complicado, ¿de acuerdo? Porque la gerencia llega y dice que necesitamos escalar, y pensamos que los servicios pasados son costosos, servicios de plataforma como servicio. Vamos a usar Kubernetes. Escuchamos que es increíble, todos los chicos geniales lo están haciendo, y es súper, súper barato. Entonces, tú, como equipo de calculadoras, de repente tienes un clúster, y piensas, ah, esto no se ve tan mal, tenemos que preocuparnos por el ingreso, tenemos que hacer el enrutamiento por nuestra cuenta y configurarlo. Pero en realidad, es un poco más complicado de lo que piensas, porque de repente tienes múltiples, digamos, almacenes de datos, ¿verdad? Tienes tu registro de contenedores para tus imágenes de Docker, y también tienes tuberías como código, así como infraestructura como código. Entonces, antes, cuando nos preocupábamos por el desencadenamiento del frontend en los backends, en qué entornos, ahora también tienes que preocuparte por tu código de infraestructura que desencadena implementaciones, lo cual también es un poco loco. Demasiados disparadores. Así que si miramos este caso con el mono-repo, ¿verdad?, estás empezando. Puedes aprender mucho haciéndolo, pero como puedes ver, ya se está volviendo bastante complicado y necesitas más habilidades. Kubernetes no es desarrollo de aplicaciones. Es mucha infraestructura con redes y seguridad que debes configurar tú mismo, y de alguna manera, está bien, puedo, en mi sandbox, romper las cosas, pero hay tantas cosas que se pueden romper fácilmente. Hagámoslo más complicado y digamos que tu gerencia llegó y pongamos todos esos servicios, ¿verdad?, tu pequeña calculadora monolítica, pongamos todos los microservicios en un clúster de Kubernetes. Y aquí ves que tenemos diferentes espacios de nombres y diferentes repositorios, y boom, muchos más disparadores y eventos que pueden ocurrir y que pueden cruzarse. Obviamente, puede que no sea un problema para ti, ¿verdad? Has practicado CICD, tus dominios son estables, pero aún así puede suceder, y es algo de lo que debes preocuparte, y probablemente te tropieces con ello durante mucho tiempo antes de dominarlo.

Ahora veamos la infraestructura porque tu gerencia, como, ahora, como, no sé, están en algún viaje de ego. Vamos a hacer Kubernetes, todas las cosas. No importa si tiene sentido. No importa si estás listo todavía. Vamos a hacer todas las cosas en Kubernetes, y de repente, te promocionan a un equipo central de infraestructura. En este diagrama, tengo tres capas diferentes, ¿verdad? Una capa de infraestructura fundamental, una capa intermedia que construye, como, una especie de plataforma extraña como servicio para otros equipos que tiene un clúster de Kubernetes, y digamos que el objetivo de la empresa es que los equipos de desarrollo de aplicaciones, en la capa dos, solo hagan, como, como en nuestro escenario anterior, nuestra primera historia, hago un cambio, lo envío, listo. Todo lo demás será gestionado por otras personas. Aún no es tan simple porque aquí tienes, por ejemplo, tengo enrutamiento, y luego tendrás certificados TLS porque queremos conexiones seguras. Entonces tienes la pregunta, espera, ¿quién tiene esos certificados, verdad? ¿Cómo puedo acceder a ellos? Si pertenecen al equipo, como ves en la capa dos en la parte superior, entonces tengo que poder, desde mi clúster, que está en una capa diferente, realmente obtener esos certificados, ¿verdad? Estoy como, oh, no quiero gestionar todo eso. Déjame poner todos los certificados conmigo en la capa cero, y eso es más fácil de configurar. Es una sola credencial tal vez. Pero luego tienes a todos estos desarrolladores golpeando tu puerta cada vez que necesitan un cambio, cada vez que algo está a punto de caducar o algo caducó, y tú no lo actualizaste, y de repente es tu culpa.

Si es su certificado, es su responsabilidad. No importa qué, probablemente tendrás personas tocando a tu puerta, ¿verdad? Porque cosas como DNS y enrutamiento, eso debe configurarse y probablemente sea esencial. No todos tienen acceso a su dominio raíz. En la mayoría de estos ejemplos, app.com. Y lo antiguo sería completar un archivo de Excel, enviármelo por correo electrónico y un día haré ese cambio de registro por ti. Un día abriré esa parte del firewall para ti. Pero a medida que creces como organización, puedes usar el inner-sourcing, ¿verdad?, bifurcar repositorios y solicitudes de extracción para agilizar eso. Lo último que quiero mencionar aquí es que hay un registro de contenedores que hemos dado al propio equipo de aplicaciones para que tengan control sobre sus propias imágenes, para que un equipo no pueda perjudicar a otro equipo sobrescribiendo accidentalmente su imagen, por ejemplo. Así que esa es una decisión de seguridad que tomamos, pero, de nuevo, tenemos el desafío de configurar varios clústeres de Kubernetes para saber a qué contenedor ir, para extraer una imagen y luego poder tener acceso para extraer esas imágenes. Retrocediendo un poco, con el inner-source y ejemplos de código. Estos son en realidad dos ejemplos de repositorios de código abierto que tengo. Usé Terraform para hacer infraestructura como código porque es más fácil de leer, y en el lado izquierdo verás un ejemplo de cómo podrías hacer eso. Incluso podrías extrapolar parte de Terraform y simplemente crear una variable. Los equipos de desarrollo de aplicaciones no necesitan conocer Terraform, ¿verdad? Pero cualquier persona que pueda escribir unas pocas líneas de código en cualquier lenguaje puede leer este archivo y hacer un cambio. Del mismo modo, lo que quiero mostrar en el lado derecho es un mal ejemplo de inner-source, pero la cuestión de la seguridad, ¿verdad? Lo que no quieres hacer es tener de repente identificadores y secretos de cliente, como nombres de usuario y contraseñas, flotando por todas partes, sin mencionar el hecho de que eventualmente caducan también. Y hay formas de evitar eso, ¿verdad? Tu proveedor de la nube podría ofrecer algo como identidades administradas, como lo hacemos en Azure, y aquí puedes ver que solo estoy pasando referencias a algo. No sé qué son todas esas credenciales y no necesito saberlo. Haré otras cosas y asignaciones de roles y Azure lo resolverá por mí. Lo que quiero decir es que esto es realmente, realmente difícil. Es súper, súper difícil. En este diagrama aquí, estoy hablando de gobierno de extremo a extremo, porque lo que a menudo sucede es que cuando las personas van a la nube, dicen que lo bloquearon todo. No puedes implementar nada, ya sabes, así que hablo de Azure, pero podría ser AWS o GCP, Google Cloud Platform, lo que sea. Todo está bloqueado. Los desarrolladores no pueden hacer nada, pero se olvidaron del CICD, especialmente estas empresas nuevas. Están como, sí, estamos en el tren de DevOps. Es como, ¿puede el contratista implementar, enviar a la rama de producción? Sí. Eso no es un problema. Y si miras este diagrama, hay varios lugares con pequeños candados rojos también, porque puedes configurar secretos en varios lugares. Configuras protecciones de rama en varios lugares. Quiero evitar que el contratista implemente en la rama de producción.

Tengo que poder configurarlo. ¿Y quién tiene permiso para hacerlo? Porque si el contratista puede hacerlo, entonces, bueno, ¿adivina qué? No cumpliste tus reglas de seguridad. Así que aparte de la infraestructura, ¿verdad? Esto es súper, súper complicado, y es complicado debido a las personas, no debido a la tecnología en sí. Puedes empeorarlo con tecnología. Puedes empeorarlo con Kubernetes porque no está realmente a la altura. Pero lo más importante que quiero transmitirte es que se trata de las personas, ¿verdad? Es mucho sobre la experiencia de las personas.

Entonces no se trata de, oh, sabes, quiero contratar personas mayores, personas que tengan esas habilidades. Las personas pueden aprender esas habilidades. Puedes invertir en ellas y darles la oportunidad de aprenderlo, y la ventaja que tienes ahí es que lo están aprendiendo con tu dominio de negocio, ¿verdad? Así que tengo mucha suerte en retrospectiva de haber comenzado con el seguro, que es súper, súper complicado porque ahora cosas más pequeñas como una tienda son fáciles de hacer para mí. Todas las cosas sobre el acoplamiento y las dependencias que tienes, las limitaciones técnicas serán simplemente un reflejo de las reglas del negocio que tienes. Y algunas de ellas no las determinas tú, ¿verdad? Así que vengo de una industria cumplidora en seguros y security dice que tienes que hacer las cosas de esta manera. Tienes que tratar a un contratista de esta manera. No quiero. Pero tengo que hacerlo. Esa es más o menos la regla.

Y así estoy saltando de un lado a otro con los pros y los contras. Pero una cosa que definitivamente quiero mencionar en los contras es que en términos de security, la gente dice, okay, puedo separarlo todo, el proveedor de cloud me permite hacerlo. Eso es mucho, mucho trabajo adicional, especialmente con cosas como credenciales que pueden expirar, certificados, etc.

Y aunque todo esto parece súper, súper complicado, es totalmente factible. Correcto. Lo más importante que debes hacer es coordinar tus equipos. Si pueden caminar juntos y moverse juntos, entonces todo funciona. Minimizarás el dolor. Y en realidad, sí, esa es la gran conclusión aquí a la derecha. Habla entre ustedes. Correcto. Ya sabes, en persona, chat, videos, problemas, solicitudes de extracción, todo.

Y a la izquierda, un par de cosas técnicas a tener en cuenta es que suelo recordar a las personas que los desencadenantes crecen exponencialmente. Ya no puedo hablar inglés. He vivido demasiado tiempo en Alemania. Y por lo tanto, no subestimes esa complejidad. Cuando se trata de cuántos repositorios, cuántas canalizaciones? Pregunta a las personas que lo harán y estarán a cargo y ellos te dirán cuántos quieren. No importa lo que yo quiera. La gente siempre me pregunta. No, lo que importa es lo que ellos quieren. Y lo mismo ocurre con el nivel de complejidad, lo que les resulte cómodo, no lo que me resulte cómodo a mí. Y está bien promover tu software manualmente empujando o fusionando manualmente en las ramas de producción. Yo también lo hago. Así que lo último. Puedes encontrar parte de este código en GitHub. Muchas de las cosas que hago son de código abierto. Lo comparto todo. No me preocupo por los secretos, etc. También escribo en blogs y hago videos en YouTube.

Así que si te gustan alguno de estos ejemplos, crees que son interesantes y los pasé rápidamente a través de todos ellos. Pero quieres más detalles. Avísame en algún lugar de GitHub, blog, YouTube. Y sí, tal vez haga un video al respecto. Tal vez porque disfruto haciéndolo, pero también tengo que encontrar tiempo para hacerlo.

Bueno, eso es todo. Así que gracias por unirte a nosotros. Gran charla. El consenso es que todas las preguntas que la gente quería hacerte ya han sido cubiertas en tu charla, porque estuvo muy bien hecha.

Así que primero vamos a la pregunta que hiciste a todos los demás. Y estoy viendo los resultados, y de hecho, lo estuve viendo durante toda la charla, y antes de que terminara la charla, en realidad estaba por encima del 50% para Terraform. Ahora está un poco por debajo del 50%. No creo que sea un resultado sorprendente. Pero ¿qué piensas de los resultados? No, quiero decir, Terraform es algo estándar y es muy maduro, ¿verdad? Sabes, cuando estás construyendo algo para producción, quieres algo que aún esté aquí dentro de un año. Si sigues la ruta agnóstica de la nube, que es lo que también me interesa, entonces Terraform es genial. Me sorprende que diga 19 otros. ¿Qué es el otro? ¿Verdad? Sí. Supongo que tal vez tiene algunas cosas personalizadas, algunos scripts personalizados. La gente todavía está usando mucho, ya sabes, scripts, como lo llamaremos. Y así es como se acumula mucho legado que realmente no pueden eliminar. Algunas cosas hechas a medida que, ya sabes, construyeron incluso antes de que existieran herramientas como Terraform. Trabajé en una empresa que antes de que existiera Terraform, ya estaban haciendo automatización. Y tienen estas herramientas antiguas que no pueden deshacerse de ellas.

Pero sí, tenemos algunas preguntas de la audiencia. Jonathan pregunta, los archivos de Jenkins a veces tienden a ser muy grandes. Acabas de mencionar que separarlos en archivos funciona muy bien. He pensado que crear scripts bash es una buena manera de abstraer la lógica.

¿Qué opinas al respecto? ¿Cómo se te ocurrieron otros tipos de soluciones? Por lo tanto, es importante comprender la diferencia entre un script bash y un archivo Jenkins. Correcto. Entonces, ¿dónde colocas tu lógica y cómo puedes compartirla? Entonces, sabes, creo que como mencioné, uso muchos archivos en parte porque si los reviso más tarde, solo quiero saber qué está sucediendo. A veces puedes colocar scripts bash en un pipeline de Jenkins que puedes compartir en diferentes pipelines. Así que sí, hago algunos scripts bash, pero generalmente trato de mantenerlos al mínimo solo porque no sé, no es tan agradable de leer. Suelo poner las cosas más en archivos make. Es más fácil. Prefiero ver make install, make do this, en lugar de todo este código bash. Sé que es necesario. Correcto. Así que no es como si dijera, oh, no hagas eso. Pero creo que dependiendo de tu carga de trabajo, puedes intentar dividirlo de diferentes formas. Sé que gestionar los pipelines y las bibliotecas de Jenkins no es fácil, porque tienes que lidiar con la versión y demás. Pero como vengo de enterprise, donde quieres compartir cosas, tiendo a ir por ese camino, poniendo las cosas en una biblioteca.

Genial. Gracias. Eso fue muy útil. Bueno, tenemos una fan en la audiencia. Anna pregunta, ¿dónde puedo escucharte hablar de nuevo? Fue una charla tan buena. Eres increíble. ¿Tienes algún lugar donde compartas tus próximas charlas y lo que estás haciendo para que la gente pueda seguirte, incluso en Twitter? Sí, soy jng5 en Twitter. Así que tuiteo de vez en cuando. Pero diría que lo mejor sería seguirme en YouTube. Suelo hacer videos en YouTube, porque quiero enseñar a la gente a pescar en lugar de darles el pescado. Es divertido. Puedo ser sarcástico y atrevido. Diría que eso es lo mejor debido al mundo de Corona, en realidad. Extraño estar en el escenario y poder caminar y cosas así, pero no puedo. Estoy aquí en casa.

Pero diría que esa es probablemente la mejor manera por ahora. Y, por supuesto, tan pronto como podamos hacer otras conferencias, preferiblemente en persona, probablemente lo anunciaré en Twitter.

Genial. Así que solo un par de preguntas más. Entonces, ¿qué dirías que es lo más complicado cuando se trata de DevOps y las organizaciones en general, especialmente las grandes organizaciones?

Creo que lo más complicado de DevOps, sin importar si eres pequeño o grande, pero es más problemático si eres grande, es en realidad descubrir dónde te encuentras, ¿verdad? Todos dicen: quiero hacer DevOps y quiero ser perfecto desde el primer día. Y es tan difícil ser perfecto. Y siento que llevo haciéndolo durante muchos, muchos años. Creo que la primera vez que vi Jenkins fue hace unos 10 años. Y aún no soy perfecto. Y como viste en una de las últimas diapositivas, como la coreografía, bailar, es tan difícil tener a todos trabajando juntos al mismo ritmo, al mismo paso. E incluso yo todavía cometo esos errores ahora. Todos tienen su propio flujo de trabajo. Y si trabajas en un equipo pequeño, es mucho más fácil ponerse de acuerdo en algo, acordar un ritmo, acordar una convención de nombres. ¿Cuándo empujan las personas? Y dices: oh, no empujes ahora porque todos vamos a almorzar o algo así. Eso es más fácil de coordinar, pero tan pronto como tienes más y más personas. Y tienes que trabajar juntos de alguna manera, incluso si es solo a través de las API publicadas que tienen. O peor aún, si tienes que compartir bibliotecas de pipelines o coordinar. Como vamos a lanzar juntos. Pero como mencioné en esta charla también, en realidad tenemos un monolito distribuido, no realmente microservicios, al menos por ahora. Y eso es realmente difícil de coordinar. Y tienes que hacerlo juntos como equipo. Y siempre es un viaje. Siempre puedes ser mejor, pero es divertido así, como un desafío. Siempre hay algo nuevo que aprender. Y sí, no sé. Por eso elegí los gifs animados de baile, porque siempre puedes aprender un nuevo baile. Es cierto. Bueno, tenemos un par de preguntas más. Pero sí, siempre es algo así en el contexto de la Ley de Conway, cuanto más grande te vuelves, más fragmentado. Y luego tienes que descubrir eso.

Entonces Matt pregunta, ¿en qué situaciones sugerirías priorizar las promociones automáticas frente a las manuales? Lo más importante aquí es la prueba. ¿Cuánta prueba debes hacer de extremo a extremo para estar realmente seguro de que puedes hacerlo? Y una de las cosas que hago con los clientes es presionarlos realmente. ¿Estás seguro? ¿Estás seguro? ¿Estás seguro? Y lo que la gente no se da cuenta también es que no puedes probar todo, ¿verdad? Esas pruebas de extremo a extremo con interfaces de usuario y clics y demás, son muy costosas. Suelen ser muy poco confiables, ¿verdad?, porque necesitas mucha potencia para tener un webkit en funcionamiento y haciendo cosas. Y simplemente es poco confiable. Pero si tu software madura hasta el punto en que tienes algunas pruebas de extremo a extremo, ¿verdad? Mi preferencia es, ya sabes, que estás testing el inicio de sesión, que la security esté al menos definitivamente allí y tienes una buena cobertura de pruebas unitarias, otras pruebas de integración, entonces realmente es, en última instancia, ¿te sientes cómodo haciéndolo y depende de la complejidad de tu software? Si es solo una pieza realmente pequeña para una API y te sientes seguro, entonces adelante. Pero si no lo haces, ¿verdad?, y quieres hacerlo manualmente, no hay vergüenza en eso. Absolutamente ninguna vergüenza. Y eso es lo que mucha gente hace. Y en realidad es incluso menos estresante y más fácil de implementar en equipo y celebrar en equipo o solucionar problemas en equipo que intentar hacerlo automáticamente y simplemente tener problemas. Sí, estoy de acuerdo. No podría estar más de acuerdo. No hay problema si prefieres hacerlo manualmente. No se trata de ser genial haciendo automation.

Hay dos preguntas más, un poco largas, pero, ya sabes, para aquellos que están haciendo preguntas y no tendremos suficiente tiempo para todas ellas, Julie todavía está aquí, estará en Discord, estará en el chat espacial y en su sala de discusión, así que únete allí. Voy a elegir una de estas últimas preguntas. Voy a elegir la pregunta de Louise, porque aún no hemos escuchado de ellos. Estamos en medio de una POC, investigando nuevas herramientas en torno a CICD. Uno de los puntos críticos para elegir la herramienta es el precio y el costo de crear e incrementar la potencia de ejecución. Si tienes una licencia por cada agente o ejecutor, etc., ¿crees que está bien combinar algunas herramientas como Jenkins más GitLab CI más TeamCity para tener un equilibrio entre la experiencia del usuario y los costos? ¡Por supuesto! Y mucha gente hace eso, ¿verdad? Y no tienes que elegir solo una herramienta. Algo como Jenkins, me encanta Jenkins. Solo necesitas personas que tengan experiencia con él, que te ayuden con él y alguien que lo gestione. Y si tienes eso, entonces es genial. Adelante. Algunas personas optan por la ruta de código abierto para evitar las licencias. Si eres nuevo como organización en DevOps, entonces opta por un servicio gestionado.

Eso también está bien. Lo más importante es enviar y enviar con frecuencia. Así que mezcla y combina. Todo está bien.

Tenemos un par de preguntas más. ¡Oh, genial! Así que quédate también para el panel de Julie. Ella responderá muchas preguntas realmente útiles. William y Jonathan, agradecemos sus preguntas. Y voy a permitir que Julie las responda en Discord, ya que creo que se nos acabó el tiempo.

Muchas gracias, Julie, por unirte a nosotros y estar con nosotros. No hay problema. Y tu excelente charla. Sí, espero verte en la community, y trataremos de ver cómo puedo hacer que vengas a DevOps Days Tel Aviv. Definitivamente está en el plan, cuando sea posible. Cuando sea posible, sí. Genial. Gracias a todos. Nos vemos en la sala de discusión. Gracias.