Azure Pipelines

Hola, soy Alex de DEV STORIES DOT EU. Azure Pipelines, episodio 1 de 10. Haces un par de clics en una interfaz web, arrastras unas cuantas cajas y tu build funciona a la perfección. De repente, alguien cambia una configuración, la build se rompe y no tienes absolutamente ningún historial de quién hizo qué ni por qué. Esa es la trampa de los editores visuales, y es exactamente por eso que el salto de la Classic UI a las pipelines YAML es la base del CI/CD moderno. Azure Pipelines te ofrece dos maneras distintas de automatizar tu delivery de software. El método más antiguo es la interfaz Classic. Se basa en un portal web gráfico donde configuras las tareas mediante formularios y menús desplegables. Parece accesible cuando estás empezando. Pero a medida que tu sistema crece, el enfoque Classic se convierte en un gran problema. La configuración reside en la base de datos de Azure DevOps, completamente desconectada de tu código fuente real. Las pipelines YAML reemplazan esto con el concepto de Pipeline-as-Code. En lugar de configurar ajustes en un portal web, defines todo tu proceso de build y release en un archivo de texto plano. Haces commit de este archivo YAML directamente en tu repositorio, manteniéndolo justo al lado del código de la aplicación para el que debe hacer la build. Algunos desarrolladores dudan en dar el salto, preocupados de que una configuración basada en texto pueda restringir las features en comparación con el editor visual. Pero ese no es el caso. Las pipelines YAML ofrecen paridad total de features para continuous integration y continuous delivery. Microsoft considera la Classic UI como legacy y centra el nuevo desarrollo en YAML. Es el estándar empresarial para la repetibilidad y la auditoría. Piensa en un equipo migrando una definición de build compleja y drag-and-drop a un archivo del repositorio. En el sistema antiguo, probar un nuevo build step implicaba editar la configuración compartida de la pipeline, lo que potencialmente podía romper la build para el resto del equipo. Con YAML, la pipeline está bajo control de versiones, exactamente igual que tu aplicación. Si creas una feature branch para actualizar una dependencia principal, puedes modificar el archivo YAML en esa misma branch. La lógica de la build actualizada se aplica solo a tu branch aislada. El resto del equipo sigue usando la pipeline de la main branch sin interrupciones. Esta es la clave. Como tu pipeline ahora es simplemente un archivo de texto en Git, pasa a formar parte de tu proceso estándar de code review. Al alejarte de la UI, nadie puede alterar en secreto un deployment target ni saltarse un testing step. Cada cambio en la pipeline requiere un commit. Requiere una pull request. Requiere la aprobación de un compañero. Obtienes un registro de auditoría permanente e innegable de cada modificación. Además, el estado de tu pipeline queda vinculado para siempre al estado de tu aplicación. Si necesitas hacer un roll back a una release de hace seis meses, el archivo YAML de ese momento exacto se conserva en tu historial de Git. Tienes la garantía de contar con las instrucciones de build correctas para esa versión antigua específica del código. La transición a YAML consiste en tratar tu mecanismo de delivery con exactamente el mismo rigor de ingeniería que el software que entrega. Si estos episodios te resultan útiles y quieres apoyar el programa, puedes buscar DevStoriesEU en Patreon. Eso es todo por este episodio. ¡Gracias por escuchar y sigue programando!

Hola, soy Alex de DEV STORIES DOT EU. Azure Pipelines, episodio 2 de 10. La diferencia entre un stage y un job determina exactamente dónde fallará tu pipeline si no entiendes la asignación de agentes. Si te equivocas, podrías encontrarte con que tus build artifacts desaparecen de repente justo cuando llega el momento de ejecutar tus tests. La anatomía de un pipeline —específicamente los stages, jobs y steps— es la estructura que resuelve esto. Un pipeline es un sistema jerárquico. Esta estructura impone estrictamente cómo se divide el trabajo, dónde se ejecuta y en qué orden. La jerarquía tiene tres niveles de profundidad. Los stages contienen jobs, y los jobs contienen steps. Un stage actúa como un límite lógico. Agrupa el trabajo relacionado. En una aplicación empresarial, usas stages para separar las fases principales de tu ciclo de entrega de software. Podrías definir un stage de build, seguido de un stage de testing independiente. Por defecto, los stages se ejecutan secuencialmente. Un stage debe terminar por completo antes de que empiece el siguiente. Actúan como barreras organizativas para tu proceso general. Aquí está la clave. Los ingenieros suelen confundir stages y jobs, usándolos indistintamente. No cumplen la misma función. Un stage es puramente un contenedor lógico. Un job es un límite de ejecución físico. Un job define el entorno real donde se ejecuta tu código. Cada job se asigna a un agente, que es la máquina o el contenedor que ejecuta tus tasks. Todas las operaciones dentro de un mismo job se ejecutan en ese agente específico. Como los jobs son la unidad de ejecución, se comportan de forma diferente a los stages. Si metes tres jobs dentro de un solo stage, Azure Pipelines intentará ejecutar esos tres jobs en paralelo en tres agentes diferentes, asumiendo que tengas la capacidad disponible. Esto significa que los jobs no comparten file systems locales ni memoria. Si el job A compila el código de tu aplicación, el job B no puede simplemente acceder a los binarios compilados desde el disco local. El job B se está ejecutando en una máquina completamente diferente. Si necesitas que dos procesos compartan el mismo espacio en disco local de forma secuencial, deben ir dentro del mismo job. Dentro de un job, defines steps. Un step es el bloque de construcción más pequeño de un pipeline. Es una instrucción concreta, normalmente un task o un script. Como los steps viven dentro de un job específico, todos se ejecutan secuencialmente exactamente en el mismo agente. El step uno podría ser un task para descargar tu código fuente. El step dos podría ser un script de bash que ejecute tu compilador. Como comparten el mismo entorno de ejecución, el step dos tiene acceso directo e inmediato a los archivos que el step uno acaba de descargar. Aplica esto a la estructura de un pipeline empresarial que compila una aplicación, ejecuta unit tests y empaqueta el resultado. Creas un único stage llamado Continuous Integration. Dentro de este stage, defines dos jobs separados para acelerar la ejecución. El job uno gestiona la build principal. Sus steps hacen checkout del código, ejecutan el compilador y empaquetan el binario. El job dos gestiona el análisis estático de código y los unit tests independientes. Como son jobs separados dentro del mismo stage, se ejecutan de forma concurrente en agentes separados. No se bloquean entre sí, pero tampoco comparten un file system. Si el job dos necesita el binario creado por el job uno, debes indicarle explícitamente al job uno que publique el artifact en el storage del pipeline, y al job dos que lo descargue. La estructura determina la capacidad en tu arquitectura de continuous integration. Usa stages para organizar tu workflow de forma lógica, pero confía en los jobs para controlar exactamente dónde y cómo escala tu ejecución en diferentes máquinas. Gracias por estar ahí. Espero que hayas aprendido algo nuevo.

Hola, soy Alex de DEV STORIES DOT EU. Azure Pipelines, episodio 3 de 10. Todo pipeline necesita potencia de cálculo, pero elegir el Execution Context incorrecto puede duplicar sin que te des cuenta tus tiempos de build. Puedes escribir un código de pipeline perfecto, pero si tu build tiene que descargar gigabytes de dependencias desde cero en cada ejecución, tu equipo perderá horas esperando. Ese cuello de botella es exactamente la razón por la que necesitas entender el Execution Context, específicamente los Agents y los Demands. Para hacer builds de código o hacer deploy de software en Azure DevOps, necesitas un agente. Un agente es simplemente un software instalable que se conecta a tu organización de Azure DevOps, espera jobs y los ejecuta uno a uno. Cada agente se ejecuta en una máquina host, y por lo general eliges entre dos tipos de hosts. Puedes usar agentes Microsoft-hosted, o puedes usar agentes self-hosted. Los agentes Microsoft-hosted son la opción por defecto por comodidad. Pides una máquina y Microsoft te da una de su pool en la nube. Nunca tienes que parchear el sistema operativo ni actualizar el software del agente. Pero esta comodidad tiene trampa y hace tropezar a muchos equipos. Esta es la clave: un agente Microsoft-hosted te da una máquina virtual totalmente nueva y limpia para cada ejecución del pipeline. No recuerda tu último build. Cuando tu job termina, esa máquina se destruye para siempre. Si tu build necesita una cache de paquetes de varios gigabytes, la descargará por la red desde cero en cada ejecución, a menos que añadas pasos explícitos de cache en el pipeline para guardar y restaurar esos datos. Si quieres evitar descargarte el mundo entero cada vez, o si tu build necesita pasar por un firewall corporativo estricto, usas agentes self-hosted. Instalas el software del agente en tu propia infraestructura. Puede ser un servidor en tu centro de datos local o una máquina virtual persistente en tu propio tenant de la nube. Como la máquina sobrevive entre ejecuciones, tus caches de paquetes, los Software Development Kits que hayas descargado y los archivos de build incremental se quedan justo donde los dejaste. Esto acelera drásticamente los tiempos de ejecución. Si quieres un punto intermedio moderno, puedes echarle un vistazo a los Managed DevOps Pools. Estos funcionan como una alternativa de scale-set donde defines imágenes base y tamaños personalizados, y Azure se encarga del aprovisionamiento y escalado automáticos. Con esto cubrimos qué son los agentes. Ahora bien, ¿cómo sabe Azure DevOps qué agente usar para un job específico? Esto se basa en un sistema de capabilities y demands. Cada agente self-hosted reporta una lista de capabilities al servidor. Muchas de estas las descubre automáticamente el software del agente, como el tipo de sistema operativo o la ruta a herramientas instaladas como Node o Python. También puedes definir capabilities de usuario personalizadas, por ejemplo, etiquetando una máquina en concreto por tener una tarjeta gráfica específica. En la definición de tu pipeline, escribes demands para que coincidan con esas capabilities. Un demand garantiza que tu job solo se enrutará a un agente que tenga la capability exacta que pides. Imagina un escenario en el que estás compilando una aplicación de iOS. Compilar para iOS requiere Xcode, que a su vez requiere estrictamente hardware de Apple. Supón que tienes un único pool de veinte agentes self-hosted, pero solo dos de ellos son Mac Minis. Simplemente añades un demand para la capability macOS a tu job del pipeline. Cuando Azure DevOps evalúa la ejecución, filtra todas las máquinas Windows y Linux del pool, y dirige tu build de iOS directamente a uno de los Mac Minis disponibles. Tu elección de agente dicta toda la arquitectura de tu pipeline. Microsoft-hosted te saca del negocio del mantenimiento de servidores a costa de gestionar el estado tú mismo, mientras que self-hosted intercambia el mantenimiento de la infraestructura por velocidad bruta y caches persistentes. Eso es todo por este episodio. ¡Gracias por escuchar y a seguir programando!

Hola, soy Alex de DEV STORIES DOT EU. Azure Pipelines, episodio 4 de 10. Quizás pienses que tu pipeline solo se ejecuta cuando alguien hace push de un commit. Pero en un sistema maduro, los pipelines son mucho más proactivos y ejecutan diferentes tipos de validación en momentos completamente distintos. Hablamos de automatizar el workflow con triggers. Los triggers definen exactamente qué eventos hacen que se ejecute tu pipeline. El tipo más común es el trigger de integración continua, o CI. Un trigger de CI se activa automáticamente cada vez que se hace push de código a una branch específica. En tu archivo de pipeline, defines esto usando un simple bloque trigger. Puedes indicarle que escuche la branch main, pero que ignore rutas de archivo específicas, como las carpetas de documentación. Esto evita que tu pipeline pierda tiempo haciendo build de la aplicación cuando alguien solo ha corregido una errata en un archivo de texto. Esto gestiona el código que ya se está moviendo a una branch. Pero normalmente quieres detectar los errores antes de que se haga el merge. Este es el trabajo de los triggers de Pull Request. Un trigger de PR se activa cuando se abre una Pull Request o cuando se hace push de nuevos commits a esa Pull Request existente. Su propósito principal es proteger la target branch validando el código entrante. Aquí está la clave. Hay una trampa común en la que caen los desarrolladores con los triggers de PR. Cuando una Pull Request dispara un pipeline, Azure Pipelines evalúa la configuración usando el archivo YAML ubicado en la source branch, no en la target branch. La lógica que rige la validación proviene de la propia feature branch. Si haces cambios en la configuración del pipeline en tu feature branch, esos cambios se aplican a la ejecución de la PR. Los triggers de PR tienen que ser rápidos. Si configuras un trigger de PR, deberías usarlo para ejecutar operaciones rápidas, como tests unitarios y linting de código. Quieres que los desarrolladores reciban feedback en minutos. Sin embargo, algunas operaciones, como el análisis estático profundo o los análisis de seguridad exhaustivos, tardan mucho más. Un análisis de seguridad de dos horas paralizará a tu equipo si lo asocias a un trigger de PR. Esto nos lleva al tercer tipo: los triggers programados. En lugar de reaccionar al movimiento del código, los triggers programados ejecutan pipelines basándose en un reloj. Utilizan la sintaxis estándar de cron para definir días y horas específicos de ejecución del pipeline. Defines un bloque schedules en tu archivo YAML, especificas la expresión cron y listas las branches a las que quieres hacer build. Puedes combinar estos triggers para crear un workflow eficiente. Durante el día, tus triggers de PR ejecutan tests unitarios rápidos en las feature branches para mantener el desarrollo en marcha. Mientras tanto, configuras un trigger programado para lanzar ese análisis de seguridad de dos horas cada medianoche contra la branch main. Incluso puedes configurar el trigger programado para que se ejecute solo si se ha hecho merge de nuevos commits desde la noche anterior. Esto se salta la ejecución por completo durante un fin de semana tranquilo, ahorrando costes de computación. Usar estos triggers juntos te permite desacoplar el feedback rápido para los desarrolladores de la validación profunda del sistema. Los triggers no son solo botones de inicio; son los controles arquitectónicos que deciden cómo y cuándo se gastan tus recursos informáticos. Gracias por escuchar — nos vemos en la próxima.

Hola, soy Alex de DEV STORIES DOT EU. Azure Pipelines, episodio 5 de 10. Hardcodear los nombres de los entornos directamente en tus archivos YAML es una deuda técnica que puede explotar durante tu próxima migración de infraestructura. Cuando esos nombres cambien, no querrás tener que buscarlos en docenas de repositorios para actualizarlos. El State Management usando variables y Variable Groups resuelve esto centralizando tu configuración. El pipeline ya conoce gran parte de su contexto de ejecución de serie. Azure proporciona variables de sistema predefinidas para que tu pipeline conozca el entorno sin ninguna configuración manual. Por ejemplo, si necesitas saber qué rama activó la ejecución, usas Build punto SourceBranch. Si necesitas el ID único de la ejecución actual, usas Build punto BuildId. Estas se rellenan automáticamente y están listas para leerse. Cuando necesitas configuración personalizada, defines variables inline. Las colocas directamente dentro de tu archivo YAML en el bloque variables. Esto es perfecto para valores específicos de un solo pipeline, como un flag de configuración de build o una ruta de archivo local. Mantiene la lógica autocontenida. Sin embargo, las variables inline fallan cuando escalas. Imagina un escenario donde tienes tres pipelines de microservicios independientes. Todos necesitan conocer el nombre del entorno de deploy de destino y un conjunto de URLs de endpoints de la API compartidos. Si las defines inline, te estás repitiendo en tres repositorios. Si un endpoint cambia, tienes que hacer tres pull requests. La solución es un Library Variable Group. Este es un store clave-valor centralizado que se guarda dentro de la Library de Azure DevOps. Creas el grupo una vez en la interfaz de usuario, lo rellenas con los nombres de tus entornos y endpoints de la API, y luego haces referencia a ese grupo por su nombre en el bloque variables de los tres pipelines de microservicios. Cuando llega el día de la migración, actualizas el Variable Group en el portal de DevOps, y cada pipeline usa instantáneamente los nuevos valores en su siguiente ejecución. Aplicas el principio Don't Repeat Yourself, manteniendo tu configuración compartida en exactamente un lugar. Aquí está la clave. La forma en que llamas a una variable cambia cuándo Azure la evalúa. Hay dos sintaxis principales, y mezclarlas romperá tu pipeline. La primera es la sintaxis de macro, escrita como un signo de dólar seguido de paréntesis que encierran el nombre de la variable. La sintaxis de macro se evalúa en runtime. Azure reemplaza la variable justo antes de que se ejecute la tarea específica que la utiliza. La segunda es la sintaxis de template expression, escrita como un signo de dólar seguido de llaves dobles que contienen la palabra variables punto y el nombre de tu variable. Las template expressions se evalúan en compile time, antes incluso de que el pipeline empiece a ejecutarse. Si estás intentando usar una variable para decidir si un stage debería ejecutarse, o para definir un bucle sobre una lista de jobs, debes usar la sintaxis de template expression. El pipeline necesita ese valor por adelantado para construir el grafo de ejecución. Si un valor se genera dinámicamente durante la ejecución del pipeline mediante un script, debes usar la sintaxis de macro, porque el valor simplemente no existe en compile time. Domina la diferencia entre las template expressions en compile time y las macros en runtime, y eliminarás los errores de parsing de variables más frustrantes en el desarrollo de tu pipeline. Eso es todo por este episodio. ¡Hasta la próxima!

Hola, soy Alex de DEV STORIES DOT EU. Azure Pipelines, episodio 6 de 10. Ocultar un secreto en los logs de tu pipeline no significa que sea seguro si lo escribiste directamente en tu configuración de CI/CD. Cuando un administrador de base de datos rota esa contraseña, tus deployments se rompen al instante hasta que alguien actualiza manualmente el pipeline. Para solucionar esto, haces fetch de las credenciales dinámicamente usando Azure Key Vault. La gente suele definir variables secretas directamente en la UI de Azure DevOps. Haces clic en el icono del candado, el texto desaparece y das por sentado que estás seguro. Guardar secretos en la UI del pipeline crea una postura de seguridad fragmentada. Si una política de empresa obliga a rotar las credenciales cada treinta días, encontrar y actualizar cada variable del pipeline en decenas de proyectos es una pesadilla operativa. Además, pierdes la auditoría centralizada sobre quién o qué ha accedido a esos datos. El enfoque secure-by-design consiste en hacer fetch de los secretos dinámicamente en runtime desde un Key Vault de empresa. El pipeline nunca es dueño del secreto. Simplemente lo toma prestado justo cuando lo necesita. Para conseguir esto, usas la task del pipeline de Azure Key Vault. Primero, el pipeline necesita permisos para mirar dentro de tu vault. Configuras una service connection de Azure Resource Manager en tu proyecto de DevOps. Esta conexión se basa en un Service Principal o en una Managed Identity. Luego, le das a esa identidad acceso de lectura explícito a los secretos de tu Key Vault usando role-based access control de Azure o vault access policies. Aquí está la clave. El pipeline se ejecuta como esta identidad, demostrando quién es ante Azure antes de hacer pull de cualquier dato sensible. Esto encaja en un modelo zero-trust. No existen credenciales permanentes en tu repositorio de código ni en las definiciones del pipeline. Imagina un pipeline haciendo fetch de una connection string de base de datos muy sensible justo antes de hacer deploy de un servicio backend. En la definición de tu pipeline, justo antes del paso de deployment, añades la task de Azure Key Vault versión dos. Le pasas tres inputs principales a esta task. Primero, especificas el nombre de la service connection de tu suscripción de Azure. Segundo, proporcionas el nombre de tu Key Vault. Tercero, defines una lista con los nombres de los secretos específicos que quieres descargar. Puedes pasar un asterisco como wildcard para descargarlo todo, pero los principios de least-privilege dictan que solo pidas exactamente lo que necesitas. Pides específicamente un secreto llamado production-database-connection. Cuando el pipeline llega a este paso, hace una llamada al vault. Si la identidad tiene permisos, el vault le devuelve el secreto. La task coge ese valor seguro y lo transforma automáticamente en una variable estándar del pipeline. El nombre de la nueva variable del pipeline coincide exactamente con el nombre del secreto en el vault. Tu siguiente paso de deployment ahora puede hacer referencia a esa variable para configurar la base de datos, igual que cualquier input de texto estándar. Azure Pipelines también registra este valor descargado como una variable secreta en segundo plano. Si un script imprime accidentalmente la connection string en la consola, el sistema la intercepta y reemplaza el texto real con asteriscos en los logs. El fetching dinámico asegura que, cuando el equipo de base de datos actualiza la contraseña principal en el vault, tu pipeline usa automáticamente la nueva string en su siguiente ejecución con cero intervención manual. Tu sistema de continuous delivery debería actuar como un mensajero seguro, recogiendo el maletín cerrado justo antes de la entrega, en lugar de guardar una copia permanente en el almacén. Eso es todo por este episodio. ¡Gracias por escuchar y sigue programando!

Hola, soy Alex de DEV STORIES DOT EU. Azure Pipelines, episodio 7 de 10. Los pipelines empresariales más fiables no se ejecutan a ciegas de principio a fin. Reaccionan dinámicamente cuando algo sale mal, destruyendo la infraestructura tras un fallo u omitiendo test suites pesados durante un hotfix menor. Para construir ese tipo de resiliencia, necesitas Control Dinámico: Condiciones y Expresiones. Cada job y step en Azure Pipelines tiene una condición asociada, la escribas explícitamente o no. Por defecto, el sistema aplica una condición integrada llamada succeeded. Esto significa que un step solo se ejecuta si todas sus dependencias anteriores terminaron sin lanzar un error. Si el step uno falla, el step dos se omite automáticamente. La gente suele malinterpretar cuándo ocurren estas comprobaciones. Una condición evalúa si un step debe ejecutarse, y lo hace completamente antes de que el step o job empiece. Un step nunca puede usar una condición para evaluar su propio output interno. La condición es el guardián que está en la entrada. Analiza el estado del pipeline hasta ese preciso momento y decide si el step tiene permiso para empezar. A veces necesitas explícitamente que un job se ejecute cuando un step anterior falla. Imagina un job de deploy que levanta infraestructura de pruebas temporal. Si el deploy falla a medias, el comportamiento por defecto omite el resto del pipeline. Tus servidores temporales se quedan online, quemando silenciosamente tu presupuesto en la nube. Esto lo solucionas añadiendo un job de limpieza dedicado al final del pipeline, pero cambias su condición de succeeded a failed. Ahora, este job de limpieza ignora por completo las ejecuciones exitosas. Solo se despierta para destruir la infraestructura temporal si los jobs de deploy principales fallan. No estás limitado a comprobaciones de estado básicas como succeeded, failed o always. Puedes escribir expresiones personalizadas para evaluar estados de variables y tomar decisiones de routing granulares. Azure Pipelines utiliza una sintaxis funcional para estas expresiones. En lugar de escribir símbolos matemáticos, usas funciones con nombre. Si quieres comprobar si una variable es igual a un valor específico, usas una función llamada eq. Abres paréntesis, pasas la variable del pipeline que estás comprobando, añades una coma y proporcionas el valor que esperas. Puedes combinar múltiples comprobaciones anidando estas funciones. Supón que tienes un job de release que solo debería ejecutarse si el pipeline terminó con succeeded y la branch actual es main. Empiezas con una función and. Dentro de sus paréntesis, pasas dos argumentos. El primer argumento es la función succeeded. El segundo argumento es tu función eq, que compara la variable de la source branch con el string de texto de la branch main. El job de release solo se activará si ambas sentencias se evalúan como true. Usar expresiones te permite construir pipelines que se adaptan al contexto de la ejecución. Antes de terminar, si quieres apoyar el programa, puedes buscar DevStoriesEU en Patreon, lo cual siempre se agradece. Esta es la parte que importa. La verdadera resiliencia de un pipeline no viene de prevenir todos los errores posibles, sino de usar condiciones para asegurar que tu sistema sepa exactamente cómo manejar los fallos cuando inevitablemente ocurran. Gracias por sintonizar. ¡Hasta la próxima!

Hola, soy Alex de DEV STORIES DOT EU. Azure Pipelines, episodio 8 de 10. Tienes cincuenta microservicios y acabas de actualizar la build definition de uno de ellos. Ahora tienes que copiar y pegar manualmente ese bloque YAML cuarenta y nueve veces más. Si copias y pegas código entre pipelines, estás acumulando una enorme deuda técnica y haciendo imposibles las actualizaciones de seguridad globales. La solución es la reutilización Enterprise: YAML Templates. Los templates te permiten definir la lógica del pipeline una sola vez y reutilizarla en cualquier lugar. En Azure Pipelines, los templates funcionan de dos maneras completamente diferentes: Includes y Extends. Un template Include funciona exactamente como una operación de copiar y pegar realizada por el compilador del pipeline. Tomas una secuencia común, como instalar un conjunto de dependencias o publicar un artifact, lo guardas como un archivo YAML independiente y luego lo referencias desde tu pipeline principal. Cuando se ejecuta el pipeline, extrae el contenido de ese template externo directamente a tu job o stage activo. Esto es útil para evitar repetirte, pero aun así deja al desarrollador con el control total de la estructura del pipeline. Es el desarrollador quien decide si, cuándo y dónde incluir tu template. Aquí está la clave. Cuando un equipo de plataforma central necesita aplicar reglas, no usa Includes. Usa Extends. Un template Extends le da la vuelta por completo a la estructura de control. En lugar de que el pipeline del desarrollador incorpore fragmentos de lógica, el pipeline del desarrollador declara que extiende un template central. Ese template central dicta los stages, jobs y el esqueleto general de todo el pipeline. El desarrollador solo puede pasar sus instrucciones específicas a los slots que el template deja explícitamente abiertos. Tomemos como ejemplo un requisito del equipo de seguridad. Exigen que cada microservicio ejecute un escáner de código de pruebas de seguridad de aplicaciones estáticas, o SAST, antes de que compile cualquier código. Para imponer esto, escriben un template Extends que define un job con dos steps. El primer step es el escáner SAST obligatorio. El segundo step es un placeholder para las acciones del desarrollador. El archivo del pipeline del equipo de desarrollo no hace más que apuntar a este template central y proporcionar sus build commands específicos a ese placeholder. El equipo de plataforma garantiza que el escáner se ejecute primero, todas y cada una de las veces, sin tener que auditar cincuenta archivos YAML individuales. Para pasar estos comandos u otra información a los templates, usas Template Parameters. La gente a menudo confunde los parameters con las variables, pero su comportamiento es fundamentalmente diferente. Las variables se evalúan en runtime y generalmente son solo texto poco estructurado. Los parameters se evalúan en compile time. Antes incluso de que el pipeline empiece a ejecutarse, Azure DevOps parsea los templates y resuelve todos los parameters. Como esto ocurre en compile time, los parameters ofrecen comprobaciones de seguridad estrictas. Puedes definir tipos de parameters precisos, como boolean, number o una lista de steps. Puedes imponer valores por defecto o restringir los inputs a una lista predefinida de strings permitidos. Si un desarrollador intenta pasar un string de texto a un parameter boolean, el pipeline se niega a compilar. Este tipado fuerte evita fallos en runtime y garantiza que el template se comporte exactamente como el equipo central pretendía. Al forzar que la estructura del pipeline se evalúe y se compruebe el tipado antes de que empiece la ejecución, un template Extends actúa como un límite arquitectónico. Separa por completo lo que los desarrolladores construyen de cómo la organización lo protege. Eso es todo por este episodio. ¡Gracias por escuchar y sigue construyendo!

Hola, soy Alex de DEV STORIES DOT EU. Azure Pipelines, episodio 9 de 10. Puedes escribir fácilmente un job estándar de pipeline que ejecute un shell script para hacer push de código a un servidor. Pero cuando aparece un bug crítico y alguien pregunta qué pasó exactamente a producción el martes pasado, ese job estándar no te da más que console logs. Para tener un audit trail real de qué se hizo deploy y dónde, necesitas apuntar tus deployments a Environments. Un Environment en Azure DevOps es una colección lógica de recursos a los que apuntas con un deployment. Le pones un nombre como producción o staging, y sirve como ancla de seguimiento. En lugar de usar un job de pipeline estándar para hacer push de tu código, usas una keyword especial llamada deployment job. Cuando enlazas un deployment job a un Environment, Azure DevOps rastrea automáticamente los commits y work items exactos a los que se les está haciendo deploy en ese target específico. Obtienes un historial de deployment completo en la interfaz de usuario sin escribir ninguna lógica de logging extra. Hay una gran diferencia en cómo se comportan los deployment jobs comparados con los jobs estándar. Un job estándar descarga automáticamente tu repositorio de código fuente. Un deployment job no lo hace. Por defecto, se salta por completo el paso de checkout. Esto confunde a muchos developers. La razón es sencilla. Para cuando llegas a la fase de deployment, deberías estar haciendo deploy de un artifact precompilado o una container image creada en una etapa de build anterior. Por lo general, no necesitas el código fuente en crudo en un runner de deployment. Si de verdad necesitas el repositorio de código fuente, tienes que decirle explícitamente al deployment job que haga el checkout. Cuando defines un deployment job, no pones una lista plana de tareas. Envuelves esas tareas en una deployment strategy. La estrategia más común es run once. Como su nombre indica, simplemente ejecuta tus pasos de deployment de forma secuencial contra el Environment. Si necesitas algo más complejo, puedes usar la estrategia canary. Canary te permite hacer deploy a un pequeño porcentaje de tus servidores, monitorizar si hay errores y, luego, hacer un roll out gradual de la nueva versión al resto. Esto limita el daño de una mala release. Dentro de estas estrategias, tus tareas se organizan en lifecycle hooks. Esto fuerza una estructura limpia. Primero, tienes el hook de pre-deploy, donde puedes inicializar recursos o ejecutar migraciones de base de datos. Luego viene el hook de deploy, que hace push de la nueva versión de tu aplicación. Después de eso, el hook de route-traffic se encarga de desviar las peticiones de red hacia la versión a la que acabas de hacer deploy. Finalmente, puedes usar post-route-traffic para ejecutar health checks o limpiar recursos antiguos. Si algo sale mal, también hay hooks de on-failure y on-success para gestionar rollbacks o notificaciones. Imagina un escenario donde usas la estrategia run once para hacer push de una container image a un namespace de Kubernetes. En tu pipeline, defines un deployment job apuntando a tu Environment de producción. Dentro de la estrategia run once, usas el hook de deploy para definir una tarea que coge tu artifact de contenedor ya construido y aplica el manifest de deployment al cluster. No necesitas hacer checkout del repositorio porque la container image ya está construida y almacenada en tu registry. Cuando este pipeline se ejecuta, las tareas se ejecutan y Azure DevOps registra la acción. Como apunta a un Environment, puedes abrir la interfaz, hacer clic en producción y ver exactamente qué commit lanzó la build de la imagen, qué developer lo hizo y que llegó correctamente al cluster de Kubernetes. Aquí está la clave. Pasar de un job estándar a un deployment job no solo cambia cómo está estructurado tu pipeline. Convierte tu pipeline de un script de automatización ciego a un historial de deployment totalmente rastreable. Gracias por escucharnos. ¡Hasta la próxima!

Hola, soy Alex de DEV STORIES DOT EU. Azure Pipelines, episodio 10 de 10. Nunca quieres que un pipeline automatizado haga push de una migración de base de datos masiva e irreversible a producción un viernes por la noche. Un pipeline totalmente automatizado es genial hasta que se dispara en el momento equivocado o sin supervisión humana. Aquí es donde los Enterprise Gates, específicamente los Approvals y Checks, resuelven esa tensión. Antes de examinar los checks específicos, tenemos que aclarar un malentendido muy común. Los Approvals y Checks no se definen en el archivo YAML de tu pipeline. Se configuran en la UI de Azure DevOps, directamente en el propio recurso, como un Environment o una Service Connection. Esta distinción es crucial. Si estas reglas estuvieran en el archivo YAML, un desarrollador podría editar el archivo en una feature branch, eliminar los checks de producción y saltarse los controles. Al poner la configuración en el recurso, el propietario del recurso es quien impone las reglas. Esto hace que tu compliance sea a prueba de manipulaciones. El código del pipeline simplemente pide usar el recurso, y el recurso decide si se cumplen las condiciones del deploy. Vamos a aplicar esto a un escenario concreto. Tienes un environment llamado Production. Quieres garantizar la seguridad de las releases y el compliance de ITIL sin perder tu automatización. Primero, quieres evitar los deploys durante el fin de semana. En el environment de Production, en la UI, añades un check de Business Hours. Defines la ventana de tiempo permitida, quizá de lunes a jueves, de nueve a cinco en tu zona horaria local. Si un pipeline intenta hacer deploy fuera de esta ventana, se pausa. Se queda esperando en un estado pending hasta que empiezan las Business Hours. Se acabaron las migraciones de los viernes por la noche. Después, necesitas un sanity check humano. Añades un check de Manual Approval y se lo asignas a un grupo específico, como el equipo de QA. Cuando el pipeline llega a la stage de deploy para Production, se detiene. Se envía un email al equipo de QA. Revisan los cambios y aprueban o rechazan explícitamente la run en el portal de Azure DevOps. Solo después de la aprobación se reanuda el pipeline. Incluso puedes forzar la secuencia de evaluación, requiriendo que el check de Business Hours pase antes de que se envíe la notificación de Manual Approval. Ahora, debes garantizar que no se cuele código experimental. Implementas Branch Control. Añades un check que indique que solo la main branch tiene permitido apuntar al environment de Production. Si alguien lanza el pipeline desde una feature branch, el check falla automáticamente. El deploy se bloquea antes incluso de intentar ejecutarse. Por último, está el problema de los deploys concurrentes. Si dos desarrolladores hacen merge de código con diez minutos de diferencia, podrías acabar con dos pipelines intentando actualizar la misma infraestructura de producción simultáneamente. El check de Exclusive Lock evita esta race condition. Garantiza que solo una run del pipeline pueda acceder al environment a la vez. El segundo pipeline simplemente espera en una cola hasta que el primero termina, garantizando un historial de deploy limpio y secuencial. Aquí está la clave. Los Approvals y Checks quitan el poder de hacer deploy al código del pipeline y se lo entregan al propietario de la infraestructura, creando un límite seguro e inalterable alrededor de tus sistemas críticos. Como este es el último episodio de nuestra serie de Azure Pipelines, te recomiendo muchísimo bucear en la documentación oficial de Microsoft y probar estas configuraciones de forma práctica. Si quieres sugerir temas para nuestra próxima serie, pásate por devstories dot eu. Eso es todo por este episodio. ¡Gracias por escuchar, y sigue creando!