Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022
Con las canalizaciones de lanzamiento clásico, puede implementar sus artefactos desde una amplia gama de orígenes. Con la interfaz gráfica, puede configurar la canalización para integrar y consumir artefactos de varios servicios. Además, puede vincular varios artefactos de orígenes diferentes y designar uno como origen principal en función de sus necesidades.
Orígenes de artefactos
Azure Pipelines admite una amplia gama de repositorios, servicios y plataformas de CI/CD. Al crear un lanzamiento, puede especificar la versión del origen del artefacto. De forma predeterminada, las versiones usan la versión más reciente del artefacto de origen. También puede optar por usar la compilación más reciente de una rama concreta especificando las etiquetas, una versión específica o permitir que el usuario especifique la versión en el momento de la creación de la versión.
Si vincula varios artefactos, puede especificar cuál es el origen principal (valor predeterminado). El origen del artefacto principal se usa para configurar varias variables predefinidas y también se puede usar para dar nombres a versiones.
Las opciones desplegables de la Versión predeterminada dependen del tipo de origen de la definición de compilación vinculada. Las opciones Specify at the time of release creation, Specific version y Latest son compatibles con todos los tipos de repositorio. Sin embargo, Latest from the build pipeline default branch with tags no es compatible con las definiciones de compilación XAML.
En las siguientes secciones se describe cómo trabajar con los distintos tipos de orígenes de artefactos:
Nota:
Al usar varios orígenes de artefactos, no se admite la asignación de un origen de artefacto para desencadenar una fase determinada. Si necesita esta funcionalidad, Azure Pipelines recomienda dividir la canalización de versión en varias versiones.
Azure Pipelines
Puede vincular la canalización de versión clásica a cualquier artefacto de canalización. Además, puede vincular varios artefactos y configurar desencadenadores de implementación en varios orígenes de compilación. Esta configuración creará un lanzamiento cada vez que una nueva compilación esté disponible. Las siguientes características están disponibles al usar Azure Pipelines como origen de artefactos:
| Característica | Descripción |
|---|---|
| Lanzamientos de activación automática | Las nuevas versiones se pueden crear automáticamente cuando hay disponible un nuevo artefacto (incluidas las compilaciones XAML). Haga clic en Desencadenadores de versión clásica para obtener más detalles. |
| Variables de artefacto | Se admiten varias variables de artefacto para artefactos a los que se hace referencia en una versión clásica. |
| Elementos de trabajo y confirmaciones | Vincule elementos de trabajo para verlos en los detalles del lanzamiento. Las confirmaciones se mostrarán al usar Git o TFVC. |
| Descarga de artefactos | De forma predeterminada, los artefactos de canalización se descargan al agente que ejecuta la canalización. También puede configurar un paso en la etapa para omitir la descarga del artefacto, si es necesario. |
| Fases de implementación | El resumen del pipeline enumera todas las etapas de implementación en las que se ha implementado el artefacto. |
Nota:
Para publicar su artefacto de canalización en una canalización clásica, debe agregar una tarea PublishPipelineArtifact a su canalización. En las canalizaciones YAML, se publica de manera implícita un artefacto de drop.
Limitar el ámbito de autorización del trabajo
De forma predeterminada, las versiones se ejecutan con un ámbito de autorización de trabajo de nivel de organización, lo que les permite acceder a los recursos en todos los proyectos de la organización. Esto resulta útil al vincular artefactos de canalización desde otros proyectos. Para restringir el acceso a los artefactos de un proyecto, puede habilitar Limitar el ámbito de autorización de la tarea al proyecto actual para canalizaciones de versión en la configuración del proyecto.
Para establecer el ámbito de autorización del trabajo para la organización:
Inicie sesión en su organización de Azure DevOps.
En la parte inferior izquierda, seleccione Configuración de la organización.
Seleccione Canalizaciones> *Configuración.
Activa el interruptor Limitar el ámbito de autorización de la tarea al proyecto actual para las canalizaciones de versión para restringir dicho ámbito al proyecto en curso. Esto se recomienda para mejorar la seguridad.
Para establecer el ámbito de autorización del trabajo para un proyecto específico:
Inicie sesión en su organización de Azure DevOps y vaya a su proyecto.
En la parte inferior izquierda, seleccione Configuración del proyecto.
Seleccione Canalizaciones> *Ajustes.
Activa el interruptor Limitar el ámbito de autorización del trabajo al proyecto actual para los pipelines de versiones para restringir el ámbito al proyecto actual. Esta es la configuración recomendada para mejorar la seguridad de las canalizaciones.
Nota:
Si el ámbito se establece en el nivel de organización, no se puede cambiar individualmente en cada proyecto.
Nota:
De forma predeterminada, las versiones se ejecutan con un ámbito de autorización de trabajo de nivel de colección, lo que les permite acceder a los recursos en todos los proyectos de la colección.
Azure Repos, GitHub y TFVC
Hay escenarios en los que es posible que quiera consumir artefactos directamente de distintos controles de origen sin pasarlos a través de una canalización de compilación. Por ejemplo:
Desarrollar una aplicación PHP o JavaScript que no requiera una canalización de compilación explícita.
Administrar las configuraciones de varias fases en distintos repositorios de control de versiones y consumir estos archivos de configuración directamente como parte de la canalización de implementación.
Administrar la infraestructura y la configuración como código en un repositorio de control de versiones.
Con Azure Pipelines, puedes configurar varios orígenes de artefactos en una sola pipeline de lanzamiento. Esto le permite vincular una canalización de compilación que genera archivos binarios de aplicación y un repositorio de control de versiones que almacena archivos de configuración, mediante ambos conjuntos de artefactos juntos durante la implementación.
Azure Pipelines admite Azure Repos, Team Foundation Version Control (TFVC), y repositorios de GitHub. Puede vincular una canalización de versiones a cualquier repositorio de Git o TFVC dentro de la colección de proyectos de su entorno, siempre que tenga acceso de lectura. No se requiere ninguna configuración adicional al implementar artefactos de control de versiones dentro de la misma colección.
Al vincular un repositorio de GitHub y seleccionar una rama, puede editar las propiedades predeterminadas de los tipos de artefacto después de guardar el artefacto. Esto resulta útil si cambia la rama de versión estable, lo que garantiza que las versiones de entrega continua usen la rama correcta para las versiones de artefacto más recientes. También puede especificar los detalles de la extracción, como los submódulos, la inclusión de archivos rastreados de Git-LFS y la profundidad superficial de extracción.
Al vincular una rama de TFVC, puede especificar el conjunto de cambios que se va a implementar durante la creación de una versión.
Las siguientes características están disponibles al usar Azure Repos, Git y TFVC como origen de artefactos:
| Característica | Descripción |
|---|---|
| Lanzamientos desencadenados automáticamente | Las nuevas versiones se pueden crear automáticamente cuando hay disponible un nuevo artefacto (incluidas las compilaciones XAML). Consulte Activadores de publicación para obtener más detalles. |
| Variables de artefacto | Se admiten varias variables de artefacto para artefactos a los que se hace referencia en una versión clásica. |
| Elementos de trabajo y confirmaciones | Vincule elementos de trabajo para verlos mostrados en los detalles de la versión. Las confirmaciones se mostrarán al usar Git o TFVC. |
| Descarga de artefactos | De forma predeterminada, los artefactos de canalización se descargan en el agente que ejecuta la canalización. También puede configurar un paso en la fase para omitir la descarga del artefacto, si es necesario. |
Nota:
De forma predeterminada, las versiones se ejecutan con un ámbito de autorización de trabajo de nivel de organización, lo que les permite acceder a los recursos en todos los proyectos de la organización. Esto resulta útil al vincular artefactos de canalización desde otros proyectos. Para restringir el acceso al artefacto de un proyecto, habilite Limitar el ámbito de autorización del trabajo al proyecto actual para canalizaciones de versión en la configuración del proyecto.
Nota:
De forma predeterminada, las versiones se ejecutan con un ámbito de autorización de trabajo de nivel de colección, lo que les permite acceder a los recursos en todos los proyectos de la colección. Esto resulta útil al vincular artefactos de canalización desde otros proyectos. Para restringir el acceso a los artefactos de un proyecto, active Limitar el ámbito de autorización de tareas al proyecto actual para canalizaciones de versión en la configuración del proyecto.
Azure Artifacts
A continuación se muestran algunos de los escenarios en los que puede usar Azure Artifacts como origen de artefacto:
El binario de su aplicación se publica en Azure Artifacts y desea consumir el paquete en una canalización de liberación.
Necesita paquetes adicionales almacenados en Azure Artifacts como parte del flujo de trabajo de implementación.
Al usar Azure Artifacts en la canalización de lanzamiento, debe seleccionar el feed, el paquete y la versión predeterminada para su paquete. Puede elegir la versión más reciente del paquete, usar una versión específica o especificar en el momento de la creación de la versión. Durante la implementación, el paquete se descarga en el agente que ejecuta la canalización.
Las siguientes características están disponibles al usar Azure Artifacts como origen de artefacto:
| Característica | Descripción |
|---|---|
| Despliegues de activación automática | Las nuevas versiones se pueden crear automáticamente cuando hay disponible un nuevo artefacto (incluidas las compilaciones XAML). Consulte Disparadores de lanzamiento para más detalles. |
| Variables del artefacto | Se admiten varias variables de artefacto para artefactos a los que se hace referencia en una versión clásica. |
| Elementos de trabajo y confirmaciones | Vincule elementos de trabajo para verlos presentados en los detalles del lanzamiento. Las confirmaciones se mostrarán al usar Git o TFVC. |
| Descarga de componentes | De forma predeterminada, los artefactos de canalización se descargan en el agente que ejecuta la canalización. También puede configurar un paso en la etapa para omitir la descarga del artefacto, si es necesario. |
Manejo de instantáneas de Maven
Al usar instantáneas de Maven, se pueden descargar varias versiones a la vez (ejemplo myApplication-2.1.0.BUILD-20190920.220048-3.jar, myApplication-2.1.0.BUILD-20190820.221046-2.jar, myApplication-2.1.0.BUILD-20190820.220331-1.jar). Es posible que tenga que quitar las versiones anteriores y mantener solo el artefacto más reciente antes de la implementación.
Ejecute el siguiente comando en una consola de PowerShell para quitar todas las copias excepto la que tenga el valor lexicográfico más alto.
Get-Item "myApplication*.jar" | Sort-Object -Descending Name | Select-Object -SkipIndex 0 | Remove-Item
Nota:
Puede almacenar hasta 30 instantáneas de Maven en su repositorio. Una vez alcanzado este límite, Azure Artifacts eliminará automáticamente las instantáneas anteriores para mantener solo los 25 más recientes.
Repositorio de contenedores de Azure y Docker Hub
Al implementar aplicaciones en contenedores, la imagen del contenedor primero se inserta en un registro de contenedores. A continuación, puede implementar la imagen de contenedor en Azure Web App for Containers o en un clúster de Docker o Kubernetes. Para ello, primero debe crear una conexión de servicio para autenticarse con Azure o Docker Hub. Consulte Conexión de servicio del Registro de Docker para obtener más detalles.
Las siguientes características están disponibles al usar el repositorio de Azure Container o Docker Hub como origen de artefactos:
| Característica | Descripción |
|---|---|
| Lanzamientos automáticos de activación | Las nuevas versiones se pueden crear automáticamente cuando hay disponible un nuevo artefacto (incluidas las compilaciones XAML). Consulte Desencadenadores de versión para obtener más detalles. |
| Variables de artefacto | Se admiten varias variables de artefacto para artefactos a los que se hace referencia en una versión clásica. |
| Elementos de trabajo y confirmaciones | Vincule elementos de trabajo para verlos mostrados en los detalles de la versión. Las confirmaciones se mostrarán al usar Git o TFVC. |
| Descarga de componentes | De forma predeterminada, los artefactos de canalización se descargan en el agente que ejecuta la canalización. También puede configurar un paso en la etapa para omitir la descarga del artefacto si es necesario. |
Jenkins
Para consumir artefactos de Jenkins, debe crear una conexión de servicio para autenticarse con el servidor Jenkins. Consulte Conexión de servicio Jenkins para obtener más detalles. Además, el proyecto Jenkins debe estar configurado con una acción de posconstrucción para publicar sus artefactos.
Los artefactos generados por las compilaciones de Jenkins se propagan normalmente a los repositorios de almacenamiento para archivarlos y compartirlos. Azure Blob Storage es uno de estos repositorios, permitiendo así utilizar proyectos de Jenkins que publican en Azure Storage como orígenes de artefactos en un pipeline de implementación. Azure Pipelines descargará automáticamente estos artefactos de Azure al agente que ejecuta la canalización. En este escenario, la conectividad entre el agente y el servidor jenkins no es necesaria y los agentes hospedados por Microsoft se pueden usar sin exponer el servidor Jenkins a Internet.
Las siguientes características están disponibles al usar Jenkins como origen de artefacto:
| Característica | Descripción |
|---|---|
| Lanzamientos automáticos | Las nuevas versiones se pueden crear automáticamente cuando hay disponible un nuevo artefacto (incluidas las compilaciones XAML). Consulte la sección Desencadenadores de lanzamiento para más detalles. |
| Variables de artefacto | Se admiten varias variables de artefacto para artefactos a los que se hace referencia en una versión clásica. |
| Elementos de trabajo y confirmaciones | Vincule elementos de trabajo para ver cómo se muestran en los detalles del lanzamiento. Las confirmaciones se mostrarán al usar Git o TFVC. |
| Descarga de artefactos | De forma predeterminada, los artefactos de canalización se descargan en el agente que ejecuta la canalización. También puede configurar una etapa en su fase para omitir la descarga del artefacto si es necesario. |
Nota:
Es posible que Azure Pipelines no pueda hacer ping al servidor Jenkins si está dentro de una red empresarial privada. En estos casos, puede integrar Azure Pipelines con Jenkins mediante la configuración de un agente local que tenga acceso al servidor Jenkins. Aunque no pueda ver los nombres de los proyectos de Jenkins al vincular a una canalización, puede ingresar manualmente el nombre del proyecto en el campo de texto de la dirección URL.
Alias de origen del artefacto
Para garantizar la exclusividad de cada descarga de artefactos, a cada origen de artefacto vinculado a una canalización de versión se le asigna automáticamente una ubicación de descarga específica conocida como alias de origen. Se puede acceder a esta ubicación mediante la variable: $(System.DefaultWorkingDirectory)\[source alias].
El uso de alias de origen garantiza que el cambio de nombre de un origen de artefacto vinculado no requiera editar las propiedades de la tarea, ya que la ubicación de descarga definida en el agente permanece sin cambios.
De forma predeterminada, el alias de origen es el nombre del origen del artefacto con un guion bajo como prefijo (por ejemplo, _mslearn-tailspin-spacegame-web). En función del tipo de origen del artefacto, el alias de origen puede ser el nombre de la canalización de compilación, el nombre del trabajo, el nombre del proyecto o el nombre del repositorio. Puede editar el alias de origen desde la pestaña de artefactos del pipeline de lanzamiento.
Descarga del artefacto
Cuando se completa una implementación en una etapa, los artefactos versionados de cada fuente se descargan en el agente del pipeline para que las tareas dentro de esa etapa puedan utilizarlos. Estos artefactos descargados no se eliminan cuando se completa un lanzamiento. Sin embargo, cuando se inicia una nueva versión, los artefactos anteriores se eliminan y reemplazan por los nuevos.
Se crea una carpeta única en el agente para cada pipeline de lanzamiento cuando se inicia un lanzamiento y los artefactos se descargan en esta carpeta:$(System.DefaultWorkingDirectory).
Azure Pipelines no realiza ninguna optimización para evitar volver a descargar los artefactos sin cambios si se vuelve a implementar la misma versión. Además, dado que el contenido descargado anteriormente se elimina cuando se inicia una nueva versión, Azure Pipelines no puede realizar descargas incrementales en el agente.
Para omitir las descargas automáticas de artefactos, navegue a su Pipeline de release>Tareas>Agent Job>Descarga de Artefacto y desmarque todos los artefactos o especifique los artefactos concretos que desea omitir.
Para omitir las descargas automáticas de artefactos, vaya a Canalización de versión>Tareas>Tarea del agente>Opciones adicionales y seleccione Omitir descarga de artefactos.
