Contenido del curso
Portal y configuración
Boards y repositorios
Integración continua y despliegue continuo
- 14

Creación y configuración de Pylons en Azure DevOps
09:45 min - 15

Pipeline de React en Azure DevOps con artefactos
15:41 min - 16

Releases en Azure DevOps con zip
Viendo ahora - 17

Publica tu app React en Azure Static Web Apps
13:54 min - 18

CI/CD completo en Azure DevOps sin terminal
09:17 min - 19

Marketplace de Azure DevOps con extensiones
08:28 min
Cierre curso
Releases en Azure DevOps con zip
Resumen
Configurar un release en Azure DevOps te permite tomar el artefacto generado por tu pipeline de build y desplegarlo de forma controlada en producción o en cualquier ambiente de desarrollo. Aprenderás a enlazar artefactos, activar continuous deployment y descomprimir un archivo .zip listo para publicar.
¿Qué es un release pipeline en Azure DevOps?
Un release pipeline es la sección dentro de Azure DevOps que orquesta el despliegue de tu aplicación a partir del artefacto compilado por el build pipeline. La gran ventaja es el control histórico: puedes regresar a una versión anterior si algo falla y revisar cuáles publicaciones tuvieron problemas.
¿Cuál es la diferencia entre un build pipeline y un release pipeline? El build pipeline compila tu código y genera el artefacto (por ejemplo, un .zip). El release pipeline toma ese artefacto y lo despliega en uno o varios ambientes con trazabilidad por versión.
Aunque podrías agregar la publicación dentro del mismo build, separar el release te da gobernanza y la posibilidad de promover una misma compilación entre ambientes sin reconstruir.
¿Cómo configurar artefactos y continuous deployment?
Dentro de Pipelines > Releases creas un nuevo pipeline que se divide visualmente en dos áreas: artifacts y stages. Para los artefactos, lo recomendable es enlazar el que ya produce tu build pipeline en lugar de generar uno nuevo desde cero [01:48].
Los pasos clave son:
- Seleccionar el proyecto, en este caso Platzi Reapp, y apuntar a la última versión generada por el build.
- Activar el ícono de continuous deployment para que cada nuevo artefacto dispare el flujo automáticamente.
- Definir las ramas que activan el despliegue, por ejemplo solo
master, o incluir pull requests cuando se haga merge.
Con esto, cada vez que se compile la rama configurada, el release se ejecutará sin intervención manual.
¿Cómo extraer un archivo zip dentro del release?
En la sección de stages crea un empty job y ajusta el agente: en lugar del agent pool por defecto orientado a .NET, selecciona Ubuntu latest dentro de Azure Pipelines, el mismo que usaste en el build [04:36]. Esa coherencia evita errores de compatibilidad entre ambientes.
Luego añade la tarea Extract files, que descomprime cualquier .zip encontrado en la ejecución [05:08]. La configuración sugerida es:
- Dejar el patrón por defecto para que detecte el .zip generado (por ejemplo,
118.zip, donde118es el número dinámico del build). - Definir como destino una carpeta nueva, por ejemplo
Reapp App, dentro del directorio del artefacto. - Activar clean destination directory y overwrite para garantizar una publicación limpia.
¿Qué hace la tarea Extract files en Azure DevOps? Toma el archivo .zip producido por el build y descomprime su contenido en una carpeta de destino, dejando los archivos listos para ser desplegados al servidor o servicio de hosting.
La opción continue on error existe por si quieres que el flujo siga aunque falle un paso, pero lo habitual es mantener la ejecución secuencial y detenerse ante cualquier error.
¿Cómo ejecutar y validar el release?
Una vez guardado el pipeline con un comentario claro como "agregando extracción de archivo zip", crea un nuevo release desde el botón Create release [07:45]. Azure DevOps lo pondrá en cola, mostrará el artefacto de origen y ejecutará cada stage configurado.
Al finalizar, revisa los logs de la tarea extract files para confirmar que el .zip se descomprimió correctamente y que los archivos quedaron en la carpeta destino. Ese listado es tu evidencia de que el paquete está listo para publicarse.
¿Por qué el nombre del zip cambia en cada ejecución? Porque se configuró de forma dinámica con el número del build. Cada nueva compilación produce un archivo con un identificador distinto, lo que facilita rastrear qué versión se desplegó.
Con el release funcionando y el artefacto descomprimido, ya tienes el terreno preparado para conectar el flujo a Azure y publicar la aplicación de Reapp en un servicio de hosting real. Como reto, replica este mismo release cambiando el agente a Windows y comparte tus capturas con la comunidad para comparar resultados.