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

Rate this content
Bookmark

La automatización de una única aplicación monolítica es bastante sencilla. Divídela en una parte frontal y una parte trasera y aún es manejable. Agrega más componentes o infraestructura y de repente te estarás rascando la cabeza preguntándote por qué se ejecutó o no se ejecutó una compilación. ¿Cuántos pipelines necesito? ¿Cuántos repositorios de git debería tener? Vamos a revisar casos de uso desde equipos pequeños que poseen toda su pila hasta organizaciones con unidades de TI centralizadas que administran infraestructura compartida. Aprende qué escenarios y criterios determinan cómo dividir pero no convertir en espagueti tus pipelines.

32 min
01 Jul, 2021

Video Summary and Transcription

Esta charla sobre CI/CD abarca varios casos de uso, desafíos y mejores prácticas. Se enfatiza la importancia de las personas y el aprendizaje en CI/CD, así como la complejidad de coordinar equipos y administrar infraestructura. El orador comparte ideas sobre el desarrollo frontend, los microservicios y las consideraciones de seguridad. La charla concluye con discusiones sobre archivos Jenkins, scripts bash y los desafíos de DevOps en las organizaciones.

Available in English

1. Introducción a CICD y Mi Experiencia

Short description:

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. 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. 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.

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.

2. CICD Use Cases and Mono Repo with Jenkins

Short description:

Hoy les voy a presentar varios casos de uso para CICD. Comencemos con un mono repositorio y Jenkins como servidor de compilación. Después de hacer un push a la rama principal, Jenkins implementa en el entorno de producción. Para asegurarnos de que funcione, necesitamos entrega continua y promoción automatizada. Ejecutar pruebas de extremo a extremo en la aplicación implementada ayuda a verificar su funcionalidad. Si las pruebas fallan, el trabajo se detiene. Si pasan, Jenkins realiza los cambios en la rama de producción, lo que desencadena otro trabajo para implementarlo.

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.

3. Challenges in CI-CD and Pipeline Configuration

Short description:

Es desafiante escribir pruebas, especialmente pruebas de extremo a extremo. Manejar eventos y disparadores en CI-CD puede ser complicado, con varias posibilidades para hacer un seguimiento. Poner todo junto en el pipeline no es tan fácil como parece. Los archivos YAML, utilizados en muchas plataformas de CI, pueden ser complicados con la indentación y la exclusión. Gestionar múltiples componentes, ramas y entornos agrega complejidad. Los ejemplos de Jenkins y código YAML resaltan los desafíos y problemas potenciales que pueden surgir.

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.

4. Desarrollo Frontend y Producción

Short description:

Cuando se trata del desarrollo frontend, 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.

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.

5. Microservicios, Estabilidad y Pruebas

Short description:

Cuando estás construyendo microservicios, es importante entender la diferencia entre servicios independientes y un monolito distribuido. La estabilidad no es un problema tecnológico, sino un problema de las personas. Realizar pruebas de cambios y ejecutar pruebas de extremo a extremo puede ayudar a garantizar la estabilidad de tu producto.

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.

6. Desafíos de CICD y Complejidad de Infraestructura

Short description:

Incluso si la tecnología no hace lo que esperas, es importante hablar entre nosotros. El uso de Kubernetes añade complejidad con múltiples almacenes de datos y disparadores. Gestionar la infraestructura en Kubernetes requiere habilidades adicionales. Colocar microservicios en un clúster de Kubernetes aumenta la complejidad. Promover a un equipo central de infraestructura en Kubernetes trae nuevos desafíos con certificados y acceso. Los desarrolladores dependen del equipo de infraestructura para cambios y actualizaciones.

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.

7. Inner-Sourcing, Registro de Contenedores y Seguridad

Short description:

Si es su certificado, es su responsabilidad. No todos tienen acceso a su dominio raíz. A medida que creces como organización, puedes usar el inner-sourcing para optimizar los procesos. Se proporciona un registro de contenedores al equipo de aplicaciones para que tengan control sobre sus propias imágenes. Configurar clústeres de Kubernetes y gestionar el acceso para extraer imágenes puede ser un desafío. Es importante considerar la seguridad al compartir identificadores y secretos de cliente. Las identidades administradas pueden ayudar a mitigar estos riesgos. El gobierno de extremo a extremo es crucial, ya que las empresas a menudo pasan por alto el CICD en sus implementaciones en la nube. Varias configuraciones, como secretos y protecciones de rama, ayudan a prevenir implementaciones no autorizadas.

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.

8. Importancia de las personas en CICD

Short description:

Se trata de las personas, no de la tecnología. Puedes empeorarlo con tecnología o Kubernetes, pero lo más importante es la experiencia de las personas.

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.

9. Importancia del Aprendizaje y Cumplimiento en los Negocios

Short description:

Las personas pueden aprender las habilidades necesarias, y invertir en ellas proporciona la ventaja de aprender con el dominio del negocio. Comenzar con una industria compleja como el seguro ha facilitado tareas más pequeñas. Las limitaciones técnicas reflejan las reglas del negocio, algunas de las cuales no son negociables debido a los requisitos de cumplimiento y seguridad.

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.

10. Coordination, Complexity, and Open Source

Short description:

En cuanto a la seguridad, separar todo en la nube puede ser complicado, pero se puede hacer. Coordina tus equipos y comunícate de manera efectiva. Recuerda que los desencadenantes crecen exponencialmente, así que no subestimes la complejidad. Pregunta a las personas que estarán a cargo de la operación por su opinión sobre los repositorios y las canalizaciones. También es aceptable promover el software manualmente. Puedes encontrar mi código en GitHub y comparto muchos proyectos de código abierto. También escribo en blogs y hago videos en YouTube.

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.

QnA

Summary and Q&A on Terraform and Jenkins Files

Short description:

Si te gustan alguno de estos ejemplos y quieres más detalles, avísame en GitHub, blog o YouTube. El consenso es que todas las preguntas han sido cubiertas en la charla. Los resultados muestran que Terraform es una opción estándar para construir aplicaciones listas para producción. Sin embargo, todavía hay otras opciones y sistemas heredados en uso. Tenemos una pregunta de Jonathan sobre cómo manejar archivos grandes de Jenkins y la sugerencia de usar scripts bash para abstracción.

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.

Bash Scripts, Jenkins Files, and Sharing

Short description:

Comprender la diferencia entre un script bash y un archivo Jenkins es importante. Dependiendo de tu carga de trabajo, puedes dividirlo de diferentes formas. Gestionar los pipelines y las bibliotecas de Jenkins puede ser un desafío, pero poner las cosas en una biblioteca puede ayudar con el intercambio. Sígueme en YouTube para estar al tanto de mis próximas charlas y actividades. También puedes encontrarme en Twitter como jng5.

¿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.

Challenges of DevOps in Organizations

Short description:

Lo más complicado de DevOps, sin importar si eres pequeño o grande, es en realidad descubrir dónde te encuentras. Es difícil ser perfecto y lograr que todos trabajen juntos al mismo ritmo y velocidad. Coordinar flujos de trabajo, convenciones de nombres y lanzamientos se vuelve más desafiante a medida que el equipo crece. Tener un monolito distribuido agrega complejidad. Sin embargo, es un desafío divertido con algo nuevo que aprender. En el contexto de la Ley de Conway, cuanto más grande es la organización, más fragmentada se vuelve.

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.

Automatic Promotions and Tool Combination

Short description:

En situaciones en las que necesitas priorizar las promociones automáticas frente a las manuales, la consideración clave es la cantidad de pruebas requeridas. Las pruebas de extremo a extremo con interfaces de usuario y clics pueden ser costosas y poco confiables. Es importante tener un software maduro con una buena cobertura de pruebas unitarias y pruebas de integración. Si te sientes seguro y el software no es demasiado complejo, las promociones automáticas pueden ser una buena opción. Sin embargo, no hay vergüenza en elegir promociones manuales, ya que puede ser menos estresante y más fácil solucionar problemas en equipo. Combinar herramientas como Jenkins, GitLab CI y TeamCity es una práctica común para equilibrar la experiencia del usuario y los costos, especialmente al considerar licencias y potencia de ejecución. Contar con personas experimentadas para ayudar y gestionar las herramientas es crucial, y optar por la ruta de código abierto puede ser una solución rentable para las organizaciones nuevas en DevOps.

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.

Closing Remarks and Q&A

Short description:

Lo más importante es enviar y enviar con frecuencia. Quédate para el panel de Julie también. Ella responderá preguntas útiles. Gracias, Julie, por unirte a nosotros. Espero verte en la comunidad y en DevOps Days Tel Aviv.

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

DevOps.js Conf 2022DevOps.js Conf 2022
27 min
Why is CI so Damn Slow?
We've all asked ourselves this while waiting an eternity for our CI job to finish. Slow CI not only wrecks developer productivity breaking our focus, it costs money in cloud computing fees, and wastes enormous amounts of electricity. Let’s take a dive into why this is the case and how we can solve it with better, faster tools.
DevOps.js Conf 2024DevOps.js Conf 2024
25 min
End the Pain: Rethinking CI for Large Monorepos
Scaling large codebases, especially monorepos, can be a nightmare on Continuous Integration (CI) systems. The current landscape of CI tools leans towards being machine-oriented, low-level, and demanding in terms of maintenance. What's worse, they're often disassociated from the developer's actual needs and workflow.Why is CI a stumbling block? Because current CI systems are jacks-of-all-trades, with no specific understanding of your codebase. They can't take advantage of the context they operate in to offer optimizations.In this talk, we'll explore the future of CI, designed specifically for large codebases and monorepos. Imagine a CI system that understands the structure of your workspace, dynamically parallelizes tasks across machines using historical data, and does all of this with a minimal, high-level configuration. Let's rethink CI, making it smarter, more efficient, and aligned with developer needs.
DevOps.js Conf 2024DevOps.js Conf 2024
25 min
Atomic Deployment for JS Hipsters
Deploying an app is all but an easy process. You will encounter a lot of glitches and pain points to solve to have it working properly. The worst is: that now that you can deploy your app in production, how can't you also deploy all branches in the project to get access to live previews? And be able to do a fast-revert on-demand?Fortunately, the classic DevOps toolkit has all you need to achieve it without compromising your mental health. By expertly mixing Git, Unix tools, and API calls, and orchestrating all of them with JavaScript, you'll master the secret of safe atomic deployments.No more need to rely on commercial services: become the perfect tool master and netlifize your app right at home!
DevOps.js Conf 2021DevOps.js Conf 2021
33 min
How to Build CI/CD Pipelines for a Microservices Application
Top Content
Microservices present many advantages for running modern software, but they also bring new challenges for both Deployment and Operational tasks. This session will discuss advantages and challenges of microservices and review the best practices of developing a microservice-based architecture.We will discuss how container orchestration using Kubernetes or Red Hat OpenShift can help us and bring it all together with an example of Continuous Integration and Continuous Delivery (CI/CD) pipelines on top of OpenShift.
React Advanced Conference 2022React Advanced Conference 2022
16 min
Automated Performance Regression Testing with Reassure
As developers we love to dive into performance metrics, benchmarks, compare one solution to another. Whether we enjoy it or not, we’re often required to fix performance issues in our React and React Native apps. But this process is not sustainable and prone to regressions, especially as the app and team grow. What’s worse, those issues are often discovered by your users, making their experience miserable. In my talk I’ll introduce you to Reassure—a performance regression testing library for React and React Native— which happens to be a missing piece in our automated testing and performance suites. Spotting problems before they hit production.
DevOps.js Conf 2021DevOps.js Conf 2021
9 min
How to Get CI/CD Right in 2021: A Guide to CI and CD
Software delivery is a top priority for organizations that own software, yet it remains one of the most challenging problems enterprises face today. Continuous integration (CI) and continuous delivery (CD) are software practices that allow organizations and teams to deliver code to customers quickly, safely, and repeatedly. Whether it's to improve development, operations, or security, CI/CD pipelines give engineers and teams more time to work on things that matter and less time struggling with the risk, standards, and velocity of deployments. Join this session to learn about the components of CI/CD and how to build and scale pipelines for the future.

Workshops on related topic

DevOps.js Conf 2022DevOps.js Conf 2022
76 min
Bring Code Quality and Security to your CI/CD pipeline
WorkshopFree
In this workshop we will go through all the aspects and stages when integrating your project into Code Quality and Security Ecosystem. We will take a simple web-application as a starting point and create a CI pipeline triggering code quality monitoring for it. We will do a full development cycle starting from coding in the IDE and opening a Pull Request and I will show you how you can control the quality at those stages. At the end of the workshop you will be ready to enable such integration for your own projects.
DevOps.js Conf 2022DevOps.js Conf 2022
155 min
Powering your CI/CD with GitHub Actions
Workshop
You will get knowledge about GitHub Actions concepts, like:- The concept of repository secrets.- How to group steps in jobs with a given purpose.- Jobs dependencies and order of execution: running jobs in sequence and in parallel, and the concept of matrix.- How to split logic of Git events into different workflow files (on branch push, on master/main push, on tag, on deploy).- To respect the concept of DRY (Don't Repeat Yourself), we will also explore the use of common actions, both within the same repo and from an external repo.
DevOps.js Conf 2022DevOps.js Conf 2022
124 min
Debugging JavaScript Apps in CI/CD
Workshop
- Causes of failed builds in CI/CD pipelines- Approaches to debugging (reviewing logs, accessing environments, reproducing issues)- Debugging application-related causes (failing tests, failed application builds)- Debugging pipeline-related causes (pipeline setup, environment issues, container issues)
DevOps.js Conf 2021DevOps.js Conf 2021
149 min
CI/CD 101 with CircleCI
Workshop
Continuous Integration and Continuous Delivery/Deployment (CI/CD) concepts are increasingly adopted many technology organizations and teams. CI/CD enables teams to establish processes that increase velocity, collaboration and quality of their codebase. CI/CD enables developer & operations teams to break down unnecessary silos and gain a deeper knowledge of their respective arenas.
In this workshop the participants will be introduced to the basic fundamentals of Continuous Integration and Continuous Delivery/Deployment. Participants will learn the core principles of CI/CD and have the opportunity to reinforce what they’ve learned in a hands on workshop featuring the CircleCI platform. The workshop will demonstrate CI/CD build configuration, code commits, commit builds, code testing and packaging. The participants will leave with a hands-on experience and understanding of what it takes to CI/CD.
Table of contents- Introduction to the topic of CI/CD, and motivation for it- How different kinds of JavaScript projects are built and deployed (from static sites to APIs)- Overview of common manual steps & how we might automate them- Implementing a CI/CD pipeline from 'scratch'- Overview of CircleCI orbs- Testing across multiple versions of Node- Debugging builds with SSH- Caching dependencies- Security / vuln scanning- Deploying to various outlets
Prerequisites- Code and git installed- GitHub account
github.com/CircleCI-Public/cicd-workshop-js