Subscribe
Share
Share
Embed
Dev&Ops es el espacio donde hablamos de cultura tech, compartimos anécdotas reales y damos consejos prácticos para todo entusiasta del mundo del desarrollo y la tecnología. Acompáñanos a descubrir las últimas tendencias, aprender de nuestras experiencias y recibir tips que te ayudarán a destacar en este entorno digital en constante evolución.
Douglas (00:00)
por pequeño que parezca tu sitio, por pequeña que parezca tu aplicación, puede ser en HTML y CSS, una plantilla, se va a beneficiar de un proceso de CI/CD.
implementar un CI/CD, aunque sean trabajos de la universidad, aunque sea un demo de presentación o una página pequeña, aunque no va a estar, aunque va a cambiar dos veces al año, implementar un CI/CD. Esas cosas van a enriquecer tu currículum más adelante, a pesar de que no tengas experiencia, porque van a ser agregados a tu portafolio.
Juan (00:32)
Bienvenidos sean todos a un episodio más de nuestro podcast Dev & Ops, el podcast que te ayuda a mejorar en tu área de trabajo de tecnología. Al menos esa es nuestra meta.
El día de hoy, como todas las veces anteriores o casi todas las veces anteriores, estoy aquí acompañado de mi buen amigo Douglas, quien nos trae su punto de vista profesional y con experiencia, como ya es costumbre, para un tema que nos compete el día de hoy muy, muy interesante. El día de hoy vamos a estar hablando sobre cómo preparar tu aplicación para el proceso de CI/CD.
Así que creo que todas las experiencias que ha tenido Douglas van a ser muy valiosas para todos nosotros y vamos a tratar de dar nuestros inputs. Douglas, ¿cómo has estado? Me gustaría saber cómo te trata la vida, qué hay de nuevo, qué hay de bueno.
Douglas (01:30)
qué tal. Realmente pues contento de estar aquí como siempre, siempre lo menciono y eso es una realidad. Estas conversaciones realmente me resultan a mí bastante entretenidas como alguien apasionado por tecnología en general, verdad, y también de mucho aprendizaje porque puedo aprender de vos, de tu perspectiva y a veces aquí llegamos a conclusiones que antes no habíamos pensado por nuestra propia cuenta y eso pues es bastante bueno. Y de manera general,
pues de navidad gracias a Dios por siempre, su gracia y misericordia, siempre bien, buscando estar mejor en el trabajo, pero mayormente buscando estar bien con mi familia, que es lo más importante al final del día para mí. Y con ánimos de también afrontar esta conversación, Juan, fíjate que estaba recordando justo ahorita que la primera vez que yo realmente trabajé en CI &CD propio, porque ya tenía mucha automatización para desplegar aplicaciones,
de cierta manera, ciertas aplicaciones, pero la primera vez que trabajé en un CI &CD propio, lo trabajé con vos. Trabajamos en conjunto, yo no sé si te acordás de eso, verdad, pero eso va a ser, esperaría yo que esta plática resulte un poco más entretenida.
Juan (02:41)
Si lo recuerdo.
Sí, totalmente. Fue un proceso interesante el cambiar cómo trabajábamos antes.
y cómo lo hacíamos después porque de hecho uno de los primeros proyectos como tal en los que trabajamos a la par vos y yo recuerdo que era un proyecto de Node.js entonces en este proyecto yo tenía que hacer el build en mi pc y luego pues generaba el archivo de dist de distribution creo que viene no estoy seguro se subía eso bueno era
había un proceso medio automático pero al mismo tiempo había mucha interacción manual involucrada y luego pasamos ya a CI/CD propiamente dicho fue toda una experiencia, ese proyecto fue bastante grande ahora que lo veo en retrospectiva y fue muy interesante, ahí aprendí mucho yo la verdad bien
Douglas (03:43)
Sí, sí.
Juan (03:46)
El día de hoy entonces vamos a hablar sobre CI/CD y vamos a tratar de hablar de cómo prepararnos para todas aquellas personas que tienen un proyecto ya sea pequeñito, mediano o incluso muy grande y no tengan un pipeline, lo que le llamamos nosotros un pipeline de CI/CD establecido en su empresa, en su grupo de trabajo.
Así que primero que nada Douglas me gustaría hablar para que quedemos claros a qué nos estamos refiriendo con CI/CD. Me gustaría hablar una pequeña analogía que tengo para poder explicarlo. Primero que nada CI/CD viene de Continuous Integration y Continuous Deployment si no me equivoco. Delivery, gracias.
Douglas (04:24)
Ok.
Delivery.
Juan (04:34)
Ya lo utilizo solo las siglas y luego olvido lo que realmente significa. Continuous Integration, Continuous Delivery. Así que es estar... tener una integración en nuestro proyecto que es continua, o sea, no se detiene, no hay una interacción por parte de nosotros. Lo mismo con el Continuous Delivery, es el hecho de poder enviar nuestra aplicación de manera ininterrupida y que el proceso mismo se encargue de hacer todo.
Esto yo lo veo como una, y siempre lo he visto de esta manera en mi mente, es como esas fábricas con muchos robots donde un robot ensambla una pieza, lo pasa a otra parte, ensamblan otra parte más grande y se va moviendo hasta que al final queda hecho, qué se yo, un automóvil completo. A eso le llamamos pipeline, hecho de ir llevando una secuencia de procesos y esto
procesos involucran muchas cosas que ya las vamos a ir comentando más adelante y para que al final el producto resultante esté totalmente listo. algo falla en este proceso de ensamblaje pues ese producto final se detiene, se retira y pues habría que revisar ¿qué pasó? ¿algun bug en el código o algo en la infraestructura misma podría ser?
Pero bueno, esa es como mi primera analogía que siempre se me viene a la mente Douglas cuando hablo sobre lo que es CI/CD, es este proceso ininterrumpido de llevar nuestra aplicación desde el código hasta una aplicación que está corriendo para los usuarios finales. No sé si te parece acertada o hay algo ahí que pudiéramos cambiar.
Douglas (06:30)
Me parece acertada y de hecho me llamó la atención que vos ponés como ejemplo una línea de producción donde hay robots haciendo el proceso y es que entre los beneficios o los deseos de un CI/CD pipeline definitivamente es tiempo, que la cosa pase más rápido con menos dependencia pero la automatización es de los puntos clave porque estamos buscando eliminar el error humano.
Juan (06:38)
No,
Douglas (07:00)
está de manera constante, teniendo que hacer builds de tu aplicación y estar desplegando constantemente, sobre todo cuando se tienen varios servidores o en un cluster, estar haciendo esas configuraciones manuales, estar haciendo sus builds manuales, generan errores, son propensos a errores, el error humano. Y por eso automatizar todo antes de los CI/CD pipelines se hacía con scripts. Y uno tenía una secuencia de scripts o tenía un servidor desde donde corrían los scripts.
hay muchas maneras en lo que antes se hacía, ¿no? Pero siempre se ha buscado eliminar el error humano y me causa un poco de ironía el hecho de que hoy en día a veces algunas personas están un poco preocupadas con que la inteligencia artificial va a reemplazar ciertos puestos o ciertos trabajos y la verdad es que desde siempre en tecnología hemos venido a buscar reemplazar la interacción humana.
Juan (07:32)
Sí.
Douglas (07:56)
por un proceso automatizado que esté libre de errores o que tenga menos errores. Al final libre de errores es imposible, Pero que tenga menos errores, ¿no? Entonces me generó un poco de ironía, estoy de acuerdo con tu perspectiva, pero siempre hemos buscado reemplazar al humano, nosotros mismos en nuestros procesos, así que pues no nos asustemos ni nos sorprendamos hoy en día con la inteligencia artificial.
Juan (07:56)
No,
Sí.
Sí, siempre existe esa miedo, Hace poco vi una película, se llama The Creator, y habla sobre inteligencias artificiales, que, bueno, son robots con inteligencia artificial, y la humanidad se hizo enemiga de ellos porque aparentemente una IA provocó una bomba nuclear.
y bueno spoiler alert al final ellos mencionan que no fue una guía sino que fue un error de código de una persona lo que llevó a una explosión nuclear pero bueno y no lo veo nada nada descabellado te diré lo veo muy muy plausible
Douglas (08:53)
un bug.
Un Vogue va acabar con el mundo, me estás diciendo.
Juan (09:06)
Bien, regresando un poco a lo que es el tema de hoy, entonces vamos a hablar sobre lo que es la anatomía de este pipeline de CI/CD porque queremos como darle...
por motivos del tiempo y no vamos a poder englobar todo lo que lleva un CI/CD pipeline en un video del día de hoy no lo vamos a poder hacer. Vamos a tomar la esencia del pipeline para que si no lo tienen implementado al menos se lleven lo que son los conceptos de cada una de estas partes de ensamblaje.
se lleven cada uno de estos conceptos y podamos más adelante poder expandir esto y poder implementarlo. Así que vamos a empezar por eso Douglas, cómo prepararnos, cómo preparar nuestra aplicación, qué cosas deberíamos prestarle atención dentro del flujo, dentro de todo lo que conlleva esto. Así que bueno, me gustaría, no sé si te parece que podríamos iniciar con la parte de
o te pregunto mejor dicho, ¿a qué deberíamos prestar la atención primero? ¿A la parte de la infraestructura donde se van a correr los tests y todo esto? o a la parte del código? Crear diferentes tests, crear el build de una aplicación, crear un Dockerfile. ¿Cómo lo ves en tu experiencia? Ya has tenido experiencia con diferentes tipos de proyectos.
Douglas (10:40)
Me gusta la pregunta y fíjate que en mi mente, Juan, en mi mente y esto lo que yo voy a aportar, en realidad no comenzó para alguien nuevo, alguien que viene iniciando en CI/CD, quiere entenderlo, quiere implementarlo porque sabe que lo necesita, más allá de la parte del código.
de test o acomodar tu aplicación a que pueda funcionar de esa manera. O la parte de infraestructura que es donde va a correr ese CI/CD o a donde lo vas a desplegar. Para mí es comenzar con la mentalidad.
En mi experiencia, Juan, en todo lo que hemos tenido que trabajar, como tengo muchos años trabajando en la industria, por gracias de Dios, he venido desde un proceso, ya lo he mencionado antes, desde trabajar con Bare Metal, que son los servidores físicos directamente al servidor, se instala un sistema operativo y ahí corriamos todo. Y luego cambiar la mentalidad a virtualización y crear máquinas virtuales dentro de un servidor físico. Y luego la implementación de containers y orquestración de contenedores. Y la mentalidad de cada uno de esos procesos
esos anteriores, cambiar esa mentalidad en las personas ha sido mi reto más grande. En primer lugar, yo entrar en esa mentalidad porque necesito comprender esta nueva tecnología, nueva herramienta que hoy voy a trabajar y que quiero implementar, aplicar la mentalidad correcta alrededor de ello.
Y luego transmitirse a otros, esa mentalidad. Ya he compartido aquí, Juan, esa experiencia que tuvimos cuando pasamos de máquinas virtuales a contenedores. Y esas conversaciones que había con diferentes grupos de personas dentro de la empresa, donde había que explicarles que un contenedor no se saca del clúster.
para luego examinar lo que ocurre, ¿verdad? Sino que un contenedor es descartable y tener esas conversaciones en realidad me tomó mucho tiempo. Y al final terminé de salir de ese trabajo donde vos y yo nos conocimos y con algunas personas fracasé y no logré explicarles de manera correcta eso. O tal vez son ellos que no pudieron entender, no sé, pero en fin.
Juan (12:53)
Sí, que cuesta
la migración mental. la más difícil de llevar a cabo a veces.
Douglas (12:59)
Exacto, sobre todo cuando estamos esgados hacia una forma de trabajar. Entonces eso no es diferencia Juan con CI/CD y en realidad que antes de poder entrar a lo demás yo honestamente comenzaría con la mentalidad. ¿Qué mentalidad es Juan? Mentalidad es como que yo estoy acostumbrado a hacer las cosas. ⁓ La mentalidad con la que yo comenzaría y yo te lo he platicado antes es que la gente entienda que la aplicación
O el sitio web que yo estoy trabajando va a tener un proceso de despliegue, va a tener un proceso de deployment. Ya no va a ser eso de que yo subo por FTP o por ese FTP todos los archivos. O ya no me voy a meter al servidor y le voy a dar un Docker pool y Docker run a la nueva versión de Docker. Ya no va a estar eso manual, ya no voy a hacer que me fui a Bersel o a ¿Cuál es Firebase? y estas otras. Y yo le di varios clics para
para desplegar la nueva aplicación. No, ahora va a haber un proceso de despliegue. Ya no va a haber una publicación manual porque estoy pensando en automatizar el proceso y si tengo que ir manualmente por FTP subir archivos o ir a cambiar configuraciones entonces no estoy en eso y eso es entre las diferentes cosas que hay que cambiar de mentalidad Juan pero yo honestamente mi aporte a esta conversación sería comencemos
con
cambiar la mentalidad a entender que CI/CD va a requerir de procesos automáticos, de procesos que se puedan repetir sin que yo esté presente.
Juan (14:40)
si yo recuerdo mucho, cada una de esas formas que acababa de mencionar las he hecho en el pasado pasaba a todos los archivos por FTP si no me equivoco se llamaba Putty una aplicación para Windows exacto con 2t y esa la utilizaba ⁓
Douglas (14:57)
con 2t.
Juan (15:05)
y también cuando ya era más avanzado hacía lo de ingresar al servidor, descargar con git y hacer el build ahí directamente y bueno pues son cosas que
De cierta manera es como una evolución, si alguien lo está haciendo, ok, tal vez no debería, pero pues es parte de ir creciendo, es parte de ir entendiendo cómo funciona todo, pero bueno, la idea es que hoy en día un software moderno debería implementar diferentes herramientas que ya nos ayudan con todo esto, ya no tenemos que estar.
ingresando a ningún servidor de ninguna forma. Aparte que la idea como mencionaba es automatizar. Yo lo he mencionado en otros episodios. Hay una ley no escrita donde no se despliega un viernes, pero yo digo que deberíamos poder hacerlo en caso de que sea necesario. Y eso lo podemos hacer siempre y cuando tengamos un pipeline muy bien hecho, pruebas unitarias bien hechas.
y si, ⁓ creo que aquí las personas que nos están escuchando están interesadas en cambiar su su mentalidad para poder hacer esto y ellos van a ser los encargados de transmitirlo a su equipo de trabajo y bueno les anticipamos que probablemente no sea tan fácil al inicio pero pero si se puede, si se puede desde mi punto de vista bueno no desde mi punto de vista más bien desde mi experiencia
Y es algo que también vos me mencionabas anteriormente y creo que me hizo click cuando lo mencionabas. Es el hecho de que como, bueno, al ser developer, ser desarrollador, estoy más en contacto con ciertas partes de este proceso, de este pipeline. Más precisamente, crear un Dockerfile, crear los pasos para hacer el build de una aplicación.
Ya sea una aplicación en Node.js, PHP, C-Chart, C++, lo que sea Cada aplicación a veces requiere... El 90 % de los pasos van a ser iguales entre cada una de las aplicaciones Pero hay dos que tres sistemitas, aplicaciones que van a requerir algo extra que recuerdo mucho una implementación que teníamos de un sistema... Un sistema de SSO que teníamos
donde teníamos que en el build inyectar un binario, reemplazar un archivo, leerlo, un archivo xml, luego reemplazar ciertos valores, todo esto a través de batch scripting. Recuerdo que teníamos eso y bueno, eso tenía un pipeline diferente a cualquier otra aplicación. Así que como developer, como que ya tenemos esa primera entrada.
de los pasos que se siguen en el proceso. Lo que pasa es que los hacemos de manera local. De manera, pues, en mi PC lo hago, funciona, pruebo y sigo adelante. Pero al menos ya tenemos esa primera entrada a este proceso, ¿no Douglas? Ya tenemos esta primera, pues, acercamiento a lo que va a ocurrir.
en un proceso ya automatizado, ya sin que nosotros tengamos que ir y escribir pues el build directamente en la línea de comandos. Ya sería a través de un proceso automatizado. Estoy seguro que las personas que están en el área de DevOps o...
bueno, probablemente si no hay un pipeline, probablemente tal vez no tengan un departamento de DevOps, pero las personas que están más en el lado de administrativo y servidores, si es admin, correcto, tengan una aproximación diferente al proceso general por la naturaleza de su trabajo, no dudas.
Douglas (18:56)
y se admeten.
Sí, que, tal cual. Cada quien en su área, vos como programador, sabes cómo hacer el build de tu aplicación y qué dependencias tiene. Entonces, eso debería ser más fácil para un programador nuevo al momento de implementar CI, CDI, porque es buscar automatizar esos procesos. Si algunas acciones las generaba por medio de un GUI, pues va a tener que buscar la manera de cómo generarlas por medio de comandos para que pueda ser un proceso repetible.
Y lo mismo con los sysadmin o el de operaciones, saben cómo publicar, si estamos hablando de web servers como Nginx o con Apache, saben qué directorio están los archivos, cómo copiar hacia ellos, qué archivos de configuración cambiar si hay que hacerlo, si hay que hacer un flush del caché, si hay que limpiar algún archivo, etcétera. Eso se hace, el de sistema va a saber más fácil cómo automatizar eso.
al final del día cuando queremos hacer la integración completa de un CI/CD.
ambas partes deberíamos de entender todo probablemente no va a ser la persona Juan que configura 100 % la parte del CD en CI CD o sea la parte del despliegue y en mi caso probablemente no voy a ser la persona que va a hacer por completo todo lo del CI o sea la parte del build y de las diferentes integraciones y test pero sí nos tocaría como profesionales entender ambos lados bien aunque no seamos nosotros verdad pero debería de
Juan (20:40)
Claro.
Douglas (20:42)
que el área que ya manejemos sea más fácil de entenderla al momento de implementarla y de forma sencilla de nuevo un CI CinePilot busca hacer
lo que hoy en día ya hacen para que tu sitio web o tu aplicación se publique, solo que de manera automática. Y para ello, obviamente existen ciertos como estándares o prácticas adoptadas por la industria que facilitan esa implementación. Al final eso es lo que buscamos, facilitarlo siguiendo estas prácticas o estándares.
Juan (21:16)
Ok, de manera muy simplificada el concepto del CI/CD creo que podría ser... existe un disparador, algo que inicia el proceso, en este caso lo más común es cuando hacemos un merge o un commit al repositorio
Esto inicia un proceso, hay un sistema que puede detectar que eso sucedió o tal vez algún webhook que podemos mandar a llamar. Entonces eso inicia el proceso. El proceso involucra varias partes. Sería correr diferentes pruebas unitarias para asegurarnos que el código nuevo no esté rompiendo algo ya existente. Al menos esa sería la finalidad más simple de un unitest.
podríamos agregarle integration test que son pruebas ya ya no son pruebas unitarias sino que estamos probando cómo diferentes partes del sistema siguen funcionando en una con la otra y bueno a la par también puede estar que estamos generando una imagen de docker para decirlo manera simple una imagen de docker o tal vez un bundle del tipo de aplicación que estemos haciendo
y ese bundle o esa imagen se puede subir a un
Registry diferente o bueno en algunos casos también se puede enviar directamente hacia el servidor aunque no sé si sea la mejor práctica no estoy muy al tanto y entre medio de eso también podríamos incluir algunas pruebas y chequeos no Douglas de como que la vida de la aplicación si funciona bien si está si no hay alguna vulnerabilidad y
si nada en ese proceso ha fallado al final lo que deberíamos hacer es un nuevo trigger, un nuevo proceso inicializado donde vamos a reemplazar el binario o la aplicación que se estaba ejecutando en nuestro servidor con la nueva imagen o el nuevo bundle digamos como de manera muy simplificada algo así serían los pasos ¿no Douglas?
vos tenés un poquito más de experiencia en pasos un poquito más internos. De mi lado, pues no he tenido la oportunidad de crearlos tan detalladamente. Me he apoyado mucho en el pasado con los GitHub Actions. Así que los GitHub Actions ha sido algo muy simple donde, como mencionaba, se ejecutan las pruebas unitarias, se asegura que el build funcione, ese build se sube al registry de GitHub, puede ser.
y luego se ejecuta el reemplazo de la imagen en el servidor. De manera muy simple, esa podría ser la parte inicial, nuestro primer acercamiento con estos procesos. ¿Qué otras cosas podríamos añadirle a esto, Douglas?
Douglas (24:32)
Fíjate Juan, que me llama la atención varias cosas, me gusta cómo obviamente lo afrontas desde una perspectiva como alguien que primariamente trabaja con Golan, porque obviamente generas un binario y la manera en que, que aparte trabajas con servicios y microservicios y idealmente vas a generar un contenedor, una imagen de contenedor, ¿no? Pero resume perfectamente todo.
Juan (24:47)
Primero se va a gozar.
Douglas (24:57)
Fijate que mi primer comentario aquí, en lugar de agregarle procesos, le voy a quitar, Juan. Le voy a quitar. Aclarando que estoy 100 % de acuerdo con vos. La anatomía mínima, saludable para un CI/CD Pipeline tiene que incluir.
El proceso de build de la aplicación, la manera que sea, ya sea el contenedor como vos dijiste, es un Node.js, verdad, el build va a incluir correr el npm install y todo ese tipo de comandos que bajan dependencias, etcétera. El proceso de build, el proceso de test que normalmente va después del build, porque lo que queremos es hacerle pruebas a la aplicación ya construida. No me sirve mucho hacerle pruebas al source code.
porque cuando construya la aplicación voy a tener un resultado diferente además muchas veces ocupa que de cierta manera está corriendo parte de la aplicación para hacerle pruebas pero en fin de acuerdo con la anatomía que diste hacemos el build hacemos las pruebas
y hacemos el despliegue de la manera que sea, contenedor, binario, copiar los archivos, etcétera. Y un post deployment que puede ser un chequeo final, llamar un endpoint de health check, puede ser limpiar el caché de algo, borrar un archivo temporal, etcétera. Esa es la anatomía mínima básica y eso es lo que nos permite, que es lo que vos dijiste hace poco.
que si fuese necesario publicar un viernes, que lo incentivemos, pero si fuese necesario, eso lo que nos va permitir. Y si lo queremos automatizar, es la manera, porque los test que hacemos, las pruebas, son las que van a identificar si la publicación está bien o no para ir a producción. ¿Verdad? Eso es anatómicamente un CI/CD saludable, lo mínimo que debe de tener.
Juan (26:37)
Sacrilegio.
lo más normalito.
Douglas (27:02)
Lo más normalito. Ahora, para que alguien se inicie Juan en CI/CD, lo mínimo que necesita realmente es el proceso de build y el proceso de despliegue. No que es...
mal interpreten lo que estoy diciendo que así lo hagan, pero si estás comenzando, si quieres entrar en CI/CD, tener una aplicación pequeña, sencilla, y aquí quiero dar otro consejo, por pequeño que parezca tu sitio, por pequeña que parezca tu aplicación, puede ser en HTML y CSS, una plantilla, se va a beneficiar de un proceso de CI/CD.
implementar un CI/CD, aunque sean trabajos de la universidad, aunque sea un demo de presentación o una página pequeña, aunque no va a estar, aunque va a cambiar dos veces al año, implementar un CI/CD. Esas cosas van a enriquecer tu currículum más adelante, a pesar de que no tengas experiencia, porque van a ser agregados a tu portafolio. Pero en fin, si alguien recién comienza, Juan, que automatice el proceso de construir y el proceso de despliegue y que despliegue primero
ambiente de desarrollo o a un ambiente de staging y que ahí manualmente haga las pruebas. ¿Si está bien?
Juan (28:15)
O sea, mi primera
meta sería eliminar este proceso donde yo ingresaba al servidor hacia Gitpool o que pasaba archivos por FTP, sino que ahora eso se haga de manera automática con este proceso.
Douglas (28:30)
Me gusta lo que acabas de decir, me gusta y solo le voy a agregar algo. Mi primera meta, Juan, es que el proceso de hacer build de la aplicación, esos comandos que yo corría manual, npm install, composer install, make build, comando que sea, verdad, y luego los agarraba todos juntos o el docker build y luego lo venía y mandaba el docker a un hub o un registry o agarraba esos archivos y lo mandaba a un lugar.
que ese proceso sea automatizado y lo que vos dijiste es que el proceso de build, de mandar la aplicación y cambiar los archivos de configuración, etc., automatizar eso primero. Ese sería mi consejo para alguien que recién comienza.
Juan (29:11)
Si, me llama la atención porque eso
también te da la pauta para... Una vez que eso funciona, el hecho de que se haga el build y se despliegue la nueva versión en el servidor a los usuarios finales, ahora ya puedo empezar a ponerle más cositas. Porque ya el primer paso ya está hecho, ya se despliega de manera correcta. Ya puedo empezar a agregarle test y si un test no falla, puedo interrumpir el proceso.
y wow, muy interesante. Empezamos de lo más mínimo y vamos agregándole cosas.
Douglas (29:43)
mira, tal cual, y aparte de eso o encima de eso, no aparte, encima de lo que vos dijiste es...
Tu equipo actual, ya sea que sea un equipo de una persona, que vos seas el todólogo por el momento, o tenés un programador y alguien, un UCS Admin, tu equipo actual ya sabe cómo hacer esos dos procesos de manera manual, o de manera semiautomática, o con un Bash Script por ahí y otro Bash Script por allá. El equipo que ya está ya puede hacer eso, ya puede hacerle ver la aplicación y ya puede publicarla, ya puede desplegarla. Entonces, eso que ya sabe hacer tu equipo.
o eso que ya sabes hacer vos como equipo de una sola persona, lo automatizamos, ya lo ponemos en formato de pipeline. Si es un GitHub Action, subimos los archivos de los Actions y aseguramos de llamar un Action y eso me va permitir entrar en ese mundo. Si es GitLab, crear el GitLab CI File, si es Jenkins, crear el Jenkins Files, de la manera que sea, Y nos aseguramos de hacer esa parte primero.
porque ya automatizar esa parte que ya sabemos hacer manual primero.
Y como vos dijiste, por eso dije agregado a lo que dijiste, una vez que ya está eso, voy a poder más fácil mi mente ir alrededor de pruebas unidades automáticas, de regression tests y de cualquier otro tipo de tests que queramos agregar, de notificaciones, de post deployment steps, de entender que es un artefact y ese tipo de cosas. Pero por eso yo dije cambiar la mentalidad y es eso que ya sabemos hacer.
automatizarlo y le voy a agregar una cosa más Juan también hay que tener la mentalidad de que tu aplicación va tener un build process un proceso de build y lo mismo que dije tu aplicación puede ser html y css verdad
Idealmente le vas a hacer un build, yo no manejo muy bien todos esos frameworks, pero se hacen builds para hacerle comprimir el CSS para que sea más óptimo, para que se descargue más rápido y se usan herramientas normalmente que corren en Node.js.
para que aunque tu aplicación sea HTML y CSS, le vas a hacer un build que los archivos queden comprimidos, óptimos, etcétera, y que se despliegue. Si estás acostumbrado a que tu aplicación no tiene un build, que vas a agarrar las cosas, las pones juntas y las subes a un servidor, esa mentalidad tiene que cambiar.
Primero, que tenga un build por pequeño que sea y segundo que tenga un proceso de despliegue y no nada de FTP. Y de nuevo, ya con eso, lo que ya sabemos hacer se automatiza como primer paso para implementar un CI/CD Pipeline.
Juan (32:27)
me llama la atención porque también va a ser nuestra responsabilidad el poder convencer a nuestro equipo de trabajo a nuestros superiores entonces va a ser más fácil convencerlos con algo que como ya mencionabas ya saben me encanta me encanta ese consejo que estás dando entonces una vez que ya tenemos eso listo
Entonces ahí es donde podemos empezar a agregarle los unit tests y las pruebas unitarias. Estas pruebas unitarias, algo que mencionabas es el hecho de tener una mentalidad de build process y que tu aplicación ya no va a tener ninguna interacción manual.
Y a mí en lo personal eso es lo que me llevó, bueno uno de los motivos a los que me llevó a utilizar Linux de manera completa en mi computadora porque quería tener una experiencia donde el ambiente local es prácticamente el mismo del ambiente del servidor en el que se está ejecutando.
Bueno, si estamos haciendo una aplicación para iOS o Android, pues ya ahí es diferente, tal vez no sea tan relevante. el punto aquí es que olvidarnos de utilizar ese tipo de... Bueno, yo recordé en este momento cuando estabas hablando sobre minificar el CSS, yo recuerdo utilizar herramientas en línea, donde subís un archivo,
te lo comprime y te lo minifica y todo y obtenía el resultado y eso es lo que yo guardaba en el repositorio. Aquí ya no podemos hacer eso. Aquí tenemos que instalar o descargar dependencias que van a hacer ese proceso automáticamente. Aunque bueno, es obvio que los frameworks
modernos ya hacen ese tipo de cosas dentro de su build process por ejemplo si yo ejecuto un npm run build en cualquiera de los frameworks que estamos utilizando muy probablemente ya hace todas estas cosas ya solo es cuestión de pasarle parámetros pero bueno el punto es eso ir incluyendo todas las cosas que necesitamos o por ejemplo cuando
en el caso de Go o cualquier otro lenguaje que se ejecuta en el servidor y tenemos que retornar el HTML ya no solamente la respuesta JSON sino el HTML ya tenemos que tener en cuenta que esos archivos de HTML van a tener que estar incluidos dentro de nuestro build process ya por ejemplo en Go es más fácil incluirlos dentro del binario completo y no por aparte
o bueno, eso es una de formas, puede estar bien estar en un CVN o algo así, no lo sé pero sí, tendría que estar y con esto me llama la reacción porque los unit tests pueden ser bastante simples y aquí un consejo que puedo darles y no sé si ya lo he mencionado antes pero cuando empezamos a agregar unit tests nos podemos ver tentados a buscar el 100 % del coverage
el 100 % coverage significa que cada una de las funciones, if statements o todas las partes de nuestro código están siendo testeadas y la verdad es que esa es una métrica que puede ser muy no es muy buena por decirlo así, no es la mejor métrica lo ideal es buscar unitas que sean realmente relevantes a la aplicación y que realmente
tengamos la seguridad de que cuando ese Unity pasa nuestra aplicación está bien. De hecho, una de las cosas, una de las grandes ventajas que vamos a empezar a notar cuando tenemos un pipeline correctamente configurado, más cuando tenemos un equipo de trabajo un poquito más grande de tres, cuatro personas, diez personas en un equipo de trabajo de desarrollo, vamos a empezar a notar que ahora cuando hacemos Code Review,
nos vamos a apoyar mucho en que los test y los pipelines se hayan ejecutado correctamente. Cuando mí me llega un pull request y tengo que hacer code review pero veo que ya de entrada falló las pruebas monetarias
pues ya ni siquiera sigo revisando el código, ya simplemente notifico a la persona encargada, hey, tu código tiene un problema, revisalo. Entonces ya eso es una de las grandes ventajas que podemos empezar a notar, que ya tenemos esta certeza, no es al 100%, tampoco, a veces los unit test dicen que todo está bien y algo pasa, pero ya tenemos una primera línea de defensa.
para asegurarnos que nuestra aplicación va a llegar al público de la mejor manera, la mejor calidad. Esa es una de las grandes ventajas cuando ya tenemos un pipeline correcto. Claro, es difícil, ¿no, Douglas? Cuando ya tenemos que quede muy bien configurado, que esté todo bien, pero al menos es algo progresivo. No vamos a tener todo desde el día 1. Recuerdo en ese proyecto que mencionabas, donde empezamos a introducir el CI/CD,
todos los días íbamos agregando cosas nuevas. Tuvimos un periodo de desarrollo de Search and Development, podríamos llamarle, muy amplio, la empresa nos dio esa libertad de poder buscar cosas y cada vez íbamos agregándole diferentes cositas desde el lado de Development y obviamente desde el lado de DevOps y SRE, le iban agregando más cosas al Pipeline.
Douglas (38:16)
Sí.
Juan (38:28)
a veces llegaba a Dulas y me decía, mira ya le agregué que podemos revisar tal cosa del código y... ok, interesante. entonces sí, no, no... Si es el caso de las personas que nos están escuchando que no tienen un pipeline definido, pues no se vayan a mortificar con querer tenerlo al 100 desde el inicio. Creo que acabas de dar una gran métrica, Dulas, de cómo podemos iniciar, algo muy simple desde...
y luego poder ir agregándole cosas más adelante.
Douglas (39:02)
Sí, fíjate que me acordaste...
cuando decís de los unit testing que no siempre, que a veces fallan, yo recuerdo cuando estábamos implementando pipeline, le presentamos los primeros pipelines a quien era la directora de IT en ese momento, y cuando hablamos de que los unit tests y que el propio developer podía hacer sus unit tests en best practices, pero como eran personas muy buenos programadores, pero venían de como muy old school, como decimos, ¿no? Muy de la vieja escuela y a veces muy cerrados.
Juan (39:17)
No,
Douglas (39:35)
en sus formas, ella estableció un equipo que escribiera los unités porque ella dijo, ya visualizo a X developers creando sus propios unités y poniendo todo solo equal pass, decía ella, ¿verdad? O sea, que iban ⁓ a manipular los unités para que dijeran que pasaron y en realidad no está probando nada. Y me llamó la atención, me resultó gracioso. Pero fíjate, Juan, que...
Juan (39:59)
No confiaba en nadie.
Douglas (40:01)
Sí, y pues bueno, como programadores, los programadores deberían de crear sus propios test de manera justa y correcta, pero esa es una cultura que se crea. Ahora, yo quisiera, Juan, agregar algo y es el hecho de tal vez asegurarnos, estamos hablando de una perspectiva en la que asumimos que quien nos ve y nos escucha entiende que es un unit test o un test.
Juan (40:04)
No,
Douglas (40:29)
y tal vez yo quisiera aclarar eso, que es que cuando tenemos un proceso automatizado, ¿verdad? Queremos que exista, queremos hacer pruebas antes de publicar, antes de desplegar, para asegurarnos que va a estar bien, porque ya no vamos a estar, como ya dijimos, ¿no? Manualmente haciendo el build, manualmente probando cosas y corriendo cositas, y luego manualmente publicando. Como eso va a pasar de manera automatizada,
queremos implementar pruebas, entre pasos, para asegurarnos que todo va bien.
Y eso es lo que nos va a dar la tranquilidad de que lo que termine en producción está bien. Y es ahí donde un CI/CD implementa, un CI/CD correcto, un CI/CD saludable, implementa diferentes tipos de pruebas. Los unit tests o las pruebas unitarias son uno de los tipos de pruebas que se implementan que la prueba unitaria, básicamente ya lo explicó Juan, es prueba una sección pequeñita del código. Puede ser una función.
Una función crítica puede ser un endpoint crítico, pero es más, es una unidad pequeña, ¿verdad? También existen los regression tests que ya prueban, que ya prueban una sección más grande de tu aplicación, pueden probar toda una funcionalidad de productos, de usuarios, ya prueba una sección más grande, ¿verdad?
o incluso puede ser un full regression test que realidad prueba la funcionalidad de toda la aplicación como tal. Esas son como las pruebas mínimas más conocidas.
hay otras pruebas, hay pruebas visuales incluso VR testing que corre de manera automática y usas diferentes servicios que abre una ventana de un navegador, inspecciona los elementos y se asegura de que visualmente se va a ver como se tiene que ver. Esto es para aplicaciones que tienen un front end, no obviamente si es un API esto no aplica pero hay cosas como VR testing y hay otro tipo de pruebas que las podemos mencionar si vos queres
Juan (42:30)
Sí.
Douglas (42:39)
pero quería aclarar eso para quienes son tal vez más nuevos en el tema y tal vez no estaban tan informados de qué lleva un pipeline porque probablemente muchas personas que nos vengan a escuchar teóricamente ya saben qué conlleva un pipeline solamente no han tenido la oportunidad de implementarlo y esperamos que estos consejos les den una guía, una luz.
Pero para quienes solo han escuchado y no tenían mucha idea, esa es la intención de los test. Y eso es, cuando Juan ha estado hablando, de implementar test en tu pipeline, son esos procesos automatizados que van haciendo pruebas para asegurarse de que el proceso está siendo exitoso y reducir los errores. Con suerte que no haya ningún error, pero en algún momento vas a ver. Pero eso es, reducir los errores.
Juan (43:31)
Bueno en lo personal debo admitir que detesto hacer unit test para frontend en ciertas muy pocas ocasiones he tenido que hacerlo y no se, es poco intuitivo para mi cuando hacemos unit test para una aplicación de backend o una aplicación de linea de comandos incluso
pues es más simple, porque tenemos funciones así que las pruebas se basan en, le doy un input y espero un output es muy muy simple, en cambio en frontend pues son pruebas un poco más complejas desde mi punto de vista, tal vez para alguien más no son tan difíciles eso me lleva entonces tú Glass, aún tenemos tiempo para hablar así que me gustaría hablar que nos dieras algunos ejemplos
de que otras cosas podemos irle agregando a nuestro pipeline con la finalidad de tener un producto que sea muy robusto o mejor dicho un producto que tenemos la certeza que funciona bien es inevitable que pueda funcionar que puedan darse errores de lógica
de bueno, programé que cuando hago una compra pues le doy dinero al cliente en vez de cobrarle, no sé, algo muy raro, ¿no? Pero más allá de eso, es muy raro ese ejemplo, más allá de eso,
¿Qué podríamos agregarle a nuestro pipeline para poder tener pues diferentes, una aplicación muy robusta? De hecho, se me viene a la mente, hoy en día tenemos muchas integraciones con inteligencia artificial, he estado jugando con algunas que unas que otras, estuve probando por ejemplo lo que es Gemini y Gemini tiene un pipeline muy interesante donde
Tenemos los unit tests, diferentes tests, también podemos decirle a la Inteligencia Artificial, revisa todos los cambios que y dime si hay algo que no estoy considerando, algo que podría llegar a fallar. Entonces son cosas que podemos ir agregando a los pipelines, un poco más modernos, más del día actual. Pero bueno, sí, eso que quisiera preguntarte, ¿qué otras cosas podemos ir agregando?
ya que desde el lado de developer pues suelo terminar mucho, en lo que son unit test, integration test y ese tipo de cosas pero más allá de eso no he tenido tanta oportunidad de agregarle más cosas
Douglas (46:15)
Sí, yo creo que me gusta la pregunta y tengo un par de cosas que, algunas cuantas cosas que agregar. Me he dado cuenta que cada vez yo digo un par para algo que es más de uno, pero no va a ser tanto. Pero si lo implementas de manera correcta, si digo un par de cosas son solo dos. Y estoy tratando.
Juan (46:37)
Son unas cuantas
cosas.
Douglas (46:40)
Entonces
son unas pocas cosas y eso ya es de tres en adelante, en verdad. Estoy tratando de mejorar mi vocabulario en ese sentido. Pero bien, tengo algunas cuantas cosas que agregar y una de ellas desde la perspectiva de operaciones de sistemas, sería primero agregar algunas pruebas a la parte de pruebas ya establecidas, Porque las que mencionamos como las mínimas comunes que van en código son unit test y regression test.
Juan (46:42)
No,
Douglas (47:11)
Yo quiero sugerir algunas pruebas que están un poco más de la mano con la parte de operaciones o la parte de infraestructura, aunque son relevantes para el código y van a afectar al código, pero son cosas que los de operaciones nos preocupamos más que alguien de operaciones. Y esto es que hacemos bastante, yo hago bastante, he buscado hacer bastante siempre, y hacemos bastante en field donde yo trabajo, pero no siempre lo miro en todos los lugares y son pruebas de vulnerabilidades en el código. Y no estoy hablando de...
Juan (47:20)
Claro.
Douglas (47:41)
En muchos lugares se agregan...
escanear la imagen del Docker container cuando ya está agregado, se agrega el pipeline y hace un scan y mira si tiene vulnerabilidades. Pero en realidad vulnerabilidades en el código, eso significa que si estás usando Node models, ¿verdad? NPM para instalar algo, un proceso en tu pipeline, para eso vas a ocupar un servicio externo, un API externo, una base de datos para ver los paquetes que estás instalando.
y las versiones de esos paquetes para que hagan un escaneo de NCI, así se le dice NCI, es en la parte de Continuous Integration, hacer un escaneo NCI de los paquetes que están instalando, comparar contra bases de datos de vulnerabilidades y ver si no existe una vulnerabilidad.
Y si lo existe, que inmediatamente notifique y para el pipeline, porque no queremos mandar a producción un paquete vulnerable. Nosotros trabajamos bastante con Composer, es un package manager para paquetes de PHP, verdad, y tenemos un servicio. De hecho, yo a nivel personal, creé un GitHub Actions, porque Fuel contribuye mucho al open source, sobre todo alrededor de WordPress, verdad, yo creé un GitHub Actions.
que revisa las vulnerabilidades de los paquetes instalados con Composer para sitios de WordPress, verdad? Y lo que hace es, tres diferentes servicios, patch tag y no me acuerdo, word friends y no me acuerdo cuál es el otro, donde comprueba contra una base de datos que los paquetes que se están instalando y la versión específica no tenga vulnerabilidades. Entonces, quiero agregar que...
Juan (49:26)
Es como un antivirus que
revisas y compara contra su base de datos.
Douglas (49:31)
No, no antivirus, no antivirus directamente, un antivirus hace eso, también revisa paquetes y mira que si están vulnerables, pero también escanea archivos como tal a ver la composición, un antivirus y a ver si encuentra. Pero sí, no está tan mal la ilustración de antivirus realmente ahorita que lo pienso, pero es básicamente eso, ve que estás instalando el paquete X.
Juan (49:32)
O sea, es bien.
Douglas (49:56)
con la versión Y y mira si esa, lo va a comparar a la base de datos y mira si esa versión tiene reporte de alguna vulnerabilidad. Y si lo encuentra va a reportar y va a decir este paquete tiene esta vulnerabilidad y detiene el pipeline, ¿verdad? Entonces es de vulnerabilidades, eso le va a quitar problemas de enviar a producción algo con posibles vulnerabilidades. Y también que se incluya, sí.
Juan (49:57)
Versión tal.
Y ahí, perdón, me imagino que uno puede
como regularlo,
el hecho de decir bueno si encuentro una vulnerabilidad no detengo el proceso pero lo reporto o lo paro totalmente y ya no dejo que se despliegue la aplicación porque bueno se me viene a la mente que pasa si es la única versión que existe y no puedo ya enviar mi código a producción en el mejor de los casos pues no lo envío no no mando una vulnerabilidad pero tal vez puede que no sé si me ocurre alguien quiera decir
lo voy a enviar porque la vulnerabilidad que existe tal vez es muy muy baja la probabilidad no sé si se me ocurre
Douglas (51:03)
Sí, tal cual. De hecho, el GitHub Action que yo trabajé para WordPress tiene un input al cual le puedes poner verdadero o falso. Y si está verdadero, va parar el pipeline por completo. Si está en falso, solamente va a reportar. ¿Y por qué lo querés? Bueno, puede haber alguien que diga, yo quiero mandar código vulnerable a producción y qué. Puede haber alguien que así quiera y que lo haga, ¿no? Que tiene la libertad de hacerlo.
Juan (51:27)
lo
voy a enviar hoy y mañana reviso cómo lo cambia
Douglas (51:30)
O puede ser alguien que que corregir un problema en producción y le parezca más importante resolverlo y ocupe publicar. Pero también hay, Juan, vulnerabilidades en paquetes que estás usando, pero no en las funcionalidades que vos estás usando de ese paquete. A veces hay paquetes que hacen librerías que te sirven para hacer formularios y tienen vulnerabilidades solo en fields, en campos, para subir archivos.
Pero vos no tenés en todos tus formularios, no estás permitiendo subir archivos. Entonces, esa vulnerabilidad no me está afectando a mí.
voy a buscar hacerle el parchear la librería pero no me urre entonces voy a seguir publicando entonces tal cual como vos decís hay muchas razones por las cuales a pesar de que el paquete o la librería esté vulnerable yo siempre necesite publicar o siempre quiere publicar y tener razón existen las maneras y si lo que están implementando no lo tiene debería de tenerlo existe la manera de hacerle un bypass así le llamamos bypass a la vulnerabilidad solo reportarla y continuar con el
Juan (52:31)
Ahí pasa,
Douglas (52:35)
pero idealmente queremos evitar que se vaya a un paquete vulnerable a producción, verdad, y en ese contexto agregar un chequeo más que simple Juan, pero ayuda bastante con performance y son chequeos de sintaxis cuando no es una aplicación compilada, verdad, porque cuando compilas el compilado te hace el chequeo de sintaxis y si encuentras un problema de sintaxis no hace el vivo.
Pero cuando no es compilado, PHP, Python, el mismo HTML y CSS, ¿verdad? Todo esto. Hacerles un chequeo de sintaxis es algo que parece tan simple, pero te va a ahorrar problemas ya en producción porque lograste capturar que no cerraste bien, que no agregaste un punto y coma y que luego cuando alguien llame esa función en específica le va dar error o que el rendimiento va a ser más lento porque estás usando versiones
que ya están listas de sacadas de mantenimiento, etc. Entonces esas dos pruebas, por sencillas que parezcan, eliminan una cantidad de errores ya en producción significativos, ¿verdad? Entonces vos me preguntaste es que agregaron pipeline, primero esas dos pruebas.
Otra cosa que se le puede agregar a los pipelines, a los CI/CD pipelines para hacerlo mejor, yo diría que son post-deployment jobs. ¿Qué es post-deployment? Es que hiciste el build, hiciste los tests, hiciste el launch, O el deployment, el despliegue de la aplicación. Pero luego del post-deployment, a veces necesitas, ya lo mencioné, veces necesitas hacer un flush del caché dentro del servidor. Entonces que exista un...
Juan (54:06)
Ok
Correcto.
Douglas (54:25)
un comando, script, una forma de ejecutar que haga ese flush del cache. Puede que necesites, por ciertos cambios, limpiar el cache del CDN, del CDN que está en el Edge, eso está en el internet, no está en tus sistemas, pero por alguna razón ocupas hacer un clear del cache en el CDN, entonces por medio del API conectarte al servicio en el que estás y hacer lo que tengas que hacer, entonces eso es un post deployment job. O también puede ser
Juan (54:39)
Sí.
Douglas (54:55)
que querrás notificar. Que cuando ya se publicó a producción mandar un mensaje a un canal de Slack específico o mandar correo a alguna persona en específico. Entonces el post deployment step va a mandar el mensaje y va a decir se publicó al ambiente tal, a la hora tal, el usuario tal y el deployment fue exitoso.
el deployment falló, etcétera. esos son post deployment jobs que sé bueno agregarlos al pipeline porque voy a recalcar. La idea es que al final todo lo que tiene que ver con el proceso de publicar la aplicación se automatice, Y cualquier cosa que se hacía manual, idealmente que se automatice. Incluso si una vez que está publicado, alguien revisaba y
Juan (55:36)
Sí.
Douglas (55:46)
luego le mandaban un correo o un mensaje al jefe, eso puede ser agregado en su CI/CD pipeline. Entonces, esas son dos de las cosas que yo le agregaría. sea, una en la parte de pruebas, dos pruebas en específico, y la otra cosa, los post-deployment jobs.
Juan (56:03)
Mm-hmm.
Sí, sí, los post-deployments son bien útiles. Principalmente he tenido mucha experiencia recibiendo notificaciones de cuando está bien. Y también cuando algo pasa, cuando hay un problema en medio del pipeline, podemos recibir notificaciones. Ya hemos hablado en otros episodios sobre notificaciones, alarmas y todo eso. Así que es muy, muy útil todo eso.
Bueno, ha sido un episodio muy interesante Douglas.
Creo que dejamos algunos temas un poco más extensos y un poco más avanzados por fuera. Probablemente los vamos a tocar en otro episodio para poder dedicarnos exclusivamente a esto de cómo mejorar los pipelines, cómo optimizarlos y cómo hacer diferentes tipos de unit tests o de diferentes tipos de tests que existen como los que nos has mencionado y existen varios. De hecho el tema de testing en general creo que da
pie para un episodio por sí solo en nuestro canal. Pero bueno, la finalidad del día de hoy, les recuerdo, era pues darles estas pequeñas pautas o una idea de qué es un CI &CD y cómo poder iniciar, cómo prepararte en tu sistema o en tu aplicación para poder introducir este nuevo concepto, nueva mentalidad, esta nueva cultura podríamos decirle.
así que bueno, sin más que agregar Douglas, solo me queda pues agradecerte por compartirnos tu experiencia y tus consejos que definitivamente son muy valiosos. Yo personalmente he tratado de aplicar muchos de los consejos que nos has dado en el podcast en mi trabajo. Claro, estoy en un trabajo donde pues no hay juniors y aún así siempre hay espacio para
la mejora. Entonces definitivamente te agradezco que nos hayas acompañado en el día de hoy. Y bueno no sé si quisieras compartir algo con nuestra audiencia antes de despedirnos.
Douglas (58:22)
No solamente pues agradecido por la oportunidad de tener la conversación, realmente espero que les sea de valor, espero que no hayamos confundido más a alguien que tal vez recién comienza con esto, el tema es bien amplio y no queremos pues extendernos en cosas que tal vez van a confundir más. Recuerden, comiencen con automatizando en un CI/CD pipeline el proceso de build y el proceso de deploy y de esa manera ya tienen un pipeline funcionando
en el cual pueden ir mejorando y el cual pueden usar para que vayan a entendiendo los diferentes conceptos. Y a mí me gustó lo que dijiste ahorita al final, la intención de ayudarlos es implementar esta cultura y es que es eso.
CI/CD Pipeline se vuelve una cultura. Es cambio de mentalidad, interactúan y se coordinan y cooperan desarrolladores con equipos de QA, incluso, porque a veces los de QA hacen las pruebas, y con el equipo de sistemas o el equipo de operaciones. Entonces, en realidad, esperando que hayan tenido valor, y yo creo que acá quedamos nosotros, Juan, comprometidos a más adelante agregar
otros episodios donde toquemos estos temas más avanzados de CI/CD, pero por lo que discutimos hoy realmente creo que si lo implementan van a recibir mucho valor.
Juan (59:49)
Es correcto.
Definitivamente hay más temas que podemos ir tocando y lo vamos a hacer. Muchas gracias a todos los han llegado hasta el final. nuevo, déjenos un comentario si llegaron hasta el final. Me gustaría darles las gracias en los comentarios y agradecerles los likes y si lo comparten. Muchísimas gracias porque eso nos ayuda a nosotros. Así que bien, nos vemos en la próxima edición de este podcast y bye.
Douglas (1:00:20)
Bye.