Artefactos de versión y orígenes de artefactos

Artifacts generados por las compilaciones de Jenkins se propagan normalmente a los repositorios de almacenamiento para archivar y compartir. Azure Blob Storage es uno de los repositorios admitidos, lo que le permite consumir proyectos de Jenkins que publican en Azure Storage como orígenes de artefactos en una canalización de versión. Las implementaciones descargan los artefactos automáticamente de Azure a los agentes. En esta configuración, no se requiere conectividad entre el agente y el servidor Jenkins. Los agentes hospedados por Microsoft se pueden usar sin exponer el servidor a Internet.

Para obtener más información sobre las funcionalidades de integración de Jenkins, vea integración Azure Pipelines contrabajos de Jenkins, Pipelines y Artifacts .

Orígenes de artefactos: Azure Container Registry, Docker, Kubernetes

Al implementar aplicaciones en contenedores, la imagen del contenedor primero se inserta en un registro de contenedores. Una vez completada la inserción, la imagen de contenedor se puede implementar en el servicio Web App for Containers o en un clúster de Docker/Kubernetes. Debe crear una conexión de servicio con credenciales para conectarse al servicio para implementar imágenes ubicadas allí o en Azure. Para obtener más información, vea Conexiones de servicio.

Las siguientes características están disponibles al usar orígenes Azure Container Registry, Docker y Kubernetes:

Orígenes de artefactos: Azure Artifacts

Los escenarios en los que puede que desee consumir estos artefactos son:

1. Tiene la compilación de la aplicación (como TFS, Azure Pipelines, TeamCity y Jenkins) publicada como un paquete para Azure Artifacts y desea consumir el artefacto en una versión.
2. Como parte de la implementación de la aplicación, necesita paquetes adicionales almacenados en Azure Artifacts.

Al vincular este tipo de artefacto a la canalización de versión, debe seleccionar la fuente, el paquete y la versión predeterminada del paquete. Puede elegir elegir la versión más reciente del paquete, usar una versión específica o seleccionar la versión en el momento de la creación de la versión. Durante la implementación, el paquete se descarga en la carpeta del agente y el contenido se extrae como parte de la ejecución del trabajo.

Las siguientes características están disponibles cuando se usan Azure Artifacts orígenes:

Control de instantáneas de Maven

En el caso de las instantáneas de Maven, se pueden descargar varias versiones a la vez (por myApplication-2.1.0.BUILD-20190920.220048-3.jar ejemplo, 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 copias antiguas y conservar solo el artefacto más reciente antes de la implementación. Ejecute el siguiente comando de PowerShell en un símbolo del sistema con privilegios elevados para quitar todas las copias excepto la que tiene el valor lexicográfico más alto:

Get-Item "myApplication*.jar" | Sort-Object -Descending Name | Select-Object -SkipIndex 0 | Remove-Item

Orígenes de artefactos: TFS externo o local

Puede usar Azure Pipelines para implementar artefactos publicados por un servidor TFS local. No es necesario que el servidor TFS esté visible en Internet; acaba de configurar un agente de automatización local. Las compilaciones de un servidor TFS local se descargan directamente en el agente local y, a continuación, se implementan en los servidores de destino especificados. No abandonarán la red empresarial. Esto le permite aprovechar todas sus inversiones en el servidor TFS local y aprovechar las funcionalidades de versión de Azure Pipelines.

Para habilitar estos escenarios, debe instalar los artefactos de TFS para Azure Pipelines extensión desde Visual Studio Marketplace. A continuación, cree una conexión de servicio con credenciales para conectarse al servidor TFS (consulte conexiones de servicio para obtener más información).

A continuación, puede vincular una canalización de compilación de TFS a la canalización de versión. Elija Compilación externa de TFS en la lista Tipo.

Las siguientes características están disponibles cuando se usan orígenes de TFS externos:

Orígenes de artefactos: TeamCity

Para realizar la integración con TeamCity, primero debe instalar los artefactos de TeamCity Azure Pipelines extensión de Marketplace.

Para consumir artefactos de TeamCity, empiece por crear una conexión de servicio con credenciales para conectarse al servidor de TeamCity (consulte conexiones de servicio para obtener más información).

A continuación, puede vincular una configuración de compilación de TeamCity a una canalización de versión. La configuración de compilación de TeamCity debe configurarse con una acción para publicar los artefactos.

Las siguientes características están disponibles cuando se usan orígenes de TeamCity:

Orígenes de artefactos: artefactos personalizados

Además de los orígenes de artefactos integrados, Azure Artifacts permite integrar cualquier origen de artefacto personalizado con el modelo de extensibilidad de artefactos. Puede conectar cualquier origen de artefacto personalizado y Azure DevOps una experiencia de usuario de primera clase e integración sin problemas.

Para obtener más información, vea Azure DevOps modelo de extensibilidad de artefactos.

Orígenes de artefactos: otros orígenes

Otros tipos de orígenes, como un repositorio de NuGet, pueden crear y exponer los artefactos. Aunque seguimos expandiendo los tipos de orígenes de artefactos admitidos en Azure Pipelines, puede empezar a usarlo sin esperar a que se admita un tipo de origen específico. Simplemente omita la vinculación de orígenes de artefactos en una canalización de versión y agregue tareas personalizadas a las fases que descargan los artefactos directamente desde el origen.

Alias de origen del artefacto

Para garantizar la unidad de cada descarga de artefacto, cada origen de artefacto vinculado a una canalización de versión se proporciona automáticamente con una ubicación de descarga específica conocida como _source alias_ . Se puede acceder a esta ubicación a través de la variable :

$(System.DefaultWorkingDirectory)\[source alias]

Esta unidad también garantiza que, si más adelante cambia el nombre de un origen de artefacto vinculado en su ubicación original (por ejemplo, cambiar el nombre de una canalización de compilación en Azure Pipelines o un proyecto en Jenkins), no es necesario editar las propiedades de la tarea porque la ubicación de descarga definida en el agente no cambia.

El alias de origen es, de forma predeterminada, el nombre del origen seleccionado al vincular el origen del artefacto, precedido de un carácter de subrayado; dependiendo del tipo de origen del artefacto, este será el nombre de la canalización de compilación, el trabajo, el proyecto o el repositorio. Puede editar el alias de origen desde la pestaña artefactos de una canalización de versión. por ejemplo, cuando se cambia el nombre de la canalización de compilación y se quiere usar un alias de origen que refleje el nombre de la canalización de compilación.

Origen principal

Al vincular varios orígenes de artefactos a una canalización de versión, uno de ellos se designa como origen del artefacto principal. El origen del artefacto principal se usa para establecer una serie de variables predefinidas. También se puede usar en la asignación de nombres a las versiones.

Descarga de artefactos

Cuando se implementa una versión en una fase, los artefactos con versiones de cada uno de los orígenes se descargan de forma predeterminada en el agente de automatización para que las tareas que se ejecutan dentro de esa fase puedan implementar estos artefactos. Los artefactos descargados en el agente no se eliminan cuando se completa una versión. Sin embargo, al iniciar la siguiente versión, los artefactos descargados se eliminan y se reemplazan por el nuevo conjunto de artefactos.

Se crea una nueva carpeta única en el agente para cada canalización de versión cuando se inicia una versión y los artefactos se descargan en esa carpeta. La $(System.DefaultWorkingDirectory) variable se asigna a esta carpeta.

Azure Pipelines actualmente no realiza ninguna optimización para evitar la descarga de los artefactos sin cambios si se vuelve a implementar la misma versión. Además, dado que el contenido descargado anteriormente siempre se elimina al iniciar una nueva versión, Azure Pipelines puede realizar descargas incrementales en el agente.

Variables de artefacto

Azure Pipelines expone un conjunto de variables predefinidas a las que puede acceder y usar en tareas y scripts; por ejemplo, al ejecutar scripts de PowerShell en trabajos de implementación. Cuando hay varios orígenes de artefactos vinculados a una canalización de versión, puede acceder a información sobre cada uno de ellos. Para obtener una lista de todas las variables de artefacto predefinidas, vea variables.

Información adicional

• Orígenes del repositorio de código en Azure Pipelines
• Artefactos de Jenkins en Azure Pipelines
• Extensión TeamCity para la integración continua
• Extensión de TFS externa para Release Management

Temas relacionados

• Canalizaciones de versión
• Fases

Ayuda y soporte técnico

• Vea la guía de solución de problemas
• Obtenga consejos en Stack Overflow y no dude en publicar preguntas, buscar respuestas o sugerir una característica en la comunidad de desarrolladores de Azure DevOps. Página de soporte técnico.

Azure Pipelines | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 - TFS 2015

Una versión es una colección de artefactos en los procesos DevOps CI/CD. Un artefacto es un componente que se puede implementar de la aplicación. Azure Pipelines implementar artefactos generados por una amplia gama de orígenes de artefactos y almacenados en diferentes tipos de repositorios de artefactos.

Al crear una canalización de versión, vincule los orígenes de artefacto adecuados a la canalización de versión. Por ejemplo, puede vincular una canalización de Azure Pipelines de compilación o un proyecto de Jenkins a la canalización de versión.

Al crear una versión, especifique la versión exacta de estos orígenes de artefactos; por ejemplo, el número de una compilación procedente de Azure Pipelines o la versión de una compilación procedente de un proyecto de Jenkins.

Una vez creada una versión, no puede cambiar estas versiones. Una versión se define fundamentalmente mediante los artefactos con versiones que la conste. A medida que implemente la versión en varias fases, implementará y validará los mismos artefactos en todas las fases.

Una canalización de versión única se puede vincular a varios orígenes de artefactos,de los cuales uno es el origen principal. En este caso, cuando se crea una versión, se especifican versiones individuales para cada uno de estos orígenes.

Artifacts son fundamentales para varias características de Azure Pipelines. Algunas de las características que dependen de la vinculación de artefactos a una canalización de versión son:

• Desencadenamiento automático de versiones. Puede configurar nuevas versiones para que se cree automáticamente cada vez que se produzca una nueva versión de un artefacto. Para obtener más información, vea Desencadenadores de implementación continua. Tenga en cuenta que la capacidad de crear automáticamente versiones solo está disponible para algunos orígenes de artefactos.

• Desencadenar condiciones. Puede configurar una versión para que se cree automáticamente o la implementación de una versión en una fase para que se desencadene automáticamente, cuando solo se cumplen condiciones específicas en los artefactos. Por ejemplo, puede configurar las versiones para que se cree automáticamente solo cuando se produzca una nueva compilación desde una rama determinada.

• Versiones del artefacto. Puede configurar una versión para que use automáticamente una versión específica de los artefactos de compilación, para usar siempre la versión más reciente o para que le permita especificar la versión cuando se crea la versión.

• Variables de artefacto. Cada artefacto que forma parte de una versión tiene metadatos asociados, expuestos a tareas a través de variables. Estos metadatos incluyen el número de versión del artefacto, la rama de código desde la que se produjo el artefacto (en el caso de artefactos de compilación o código fuente), la canalización que produjo el artefacto (en el caso de artefactos de compilación) y mucho más. Esta información es accesible en las tareas de implementación. Para obtener más información, vea Variables de artefacto.

• Elementos de trabajo y confirma. Los elementos de trabajo o confirmaciones que forman parte de una versión se calculan a partir de las versiones de los artefactos. Por ejemplo, cada compilación de Azure Pipelines está asociada a un conjunto de elementos de trabajo y confirmaciones. Los elementos de trabajo o confirmaciones de una versión se calculan como la unión de todos los elementos de trabajo y confirmaciones de todas las compilaciones entre la versión actual y la versión anterior. Tenga en cuenta Azure Pipelines puede calcular elementos de trabajo y confirmaciones solo para determinados orígenes de artefactos.

• Descarga de artefactos. Cada vez que se implementa una versión en una fase, Azure Pipelines descarga automáticamente todos los artefactos de esa versión en el agente donde se ejecuta el trabajo de implementación. El procedimiento para descargar artefactos depende del tipo de artefacto. Por ejemplo, Azure Pipelines artefactos se descargan mediante un algoritmo que descarga varios archivos en paralelo. Los artefactos de Git se descargan mediante la funcionalidad de la biblioteca de Git. Para obtener más información, vea Descarga de artefactos.

Orígenes de artefactos

Hay varios tipos de herramientas que puede usar en el proceso de ciclo de vida de la aplicación para generar o almacenar artefactos. Por ejemplo, puede usar sistemas de integración continua como Azure Pipelines, Jenkins o TeamCity para generar artefactos. También puede usar sistemas de control de versiones como Git o TFVC para almacenar los artefactos. O bien, puede usar repositorios como Azure Artifacts o un repositorio NuGet para almacenar los artefactos. Puede configurar Azure Pipelines para implementar artefactos de todos estos orígenes.

De forma predeterminada, una versión creada a partir de la canalización de versión usará la versión más reciente de los artefactos. En el momento de vincular un origen de artefacto a una canalización de versión, puede cambiar este comportamiento seleccionando una de las opciones para usar la compilación más reciente de una rama específica especificando las etiquetas, una versión específica o permitir al usuario especificar la versión cuando se crea la versión a partir de la canalización.

Si vincula más de un conjunto de artefactos, puede especificar cuál es el principal (valor predeterminado).

• Todos los tipos de repositorio admiten las siguientes opciones: Specify at the time of release creationSpecific version , y Latest .

• Latest from a specific branch with tags Las Latest from the build pipeline default branch with tags opciones y son compatibles con los siguientes tipos de repositorio: TfsGit , , y GitHubBitbucketGitHubEnterprise .

• Latest from the build pipeline default branch with tags no es compatible con las XAML definiciones de compilación.

En las secciones siguientes se describe cómo trabajar con los diferentes tipos de orígenes de artefactos.

• Azure Pipelines
• TFVC, Git y GitHub
• Jenkins
• Azure Container Registry, Docker y Kubernetes
• Azure Artifacts (NuGet, Maven, npm, Python y Universal Packages)
• TFS externo o local
• TeamCity
• Otros orígenes

Orígenes de artefactos: Azure Pipelines

Puede vincular una canalización de versión a cualquiera de las canalizaciones de compilación de Azure Pipelines o de la colección de proyectos de TFS.

Algunas de las diferencias en las funcionalidades entre las distintas versiones de TFS y Azure Pipelines son:

• TFS 2015:solo puede vincular canalizaciones de compilación desde el mismo proyecto de la colección. Puede vincular varias definiciones, pero no puede especificar versiones predeterminadas. Puede configurar un desencadenador de implementación continua solo en una de las definiciones. Cuando se vinculan varias canalizaciones de compilación, se usan las compilaciones más recientes de todas las demás definiciones, junto con la compilación que desencadenó la creación de la versión.

• TFS 2017 y versiones más recientes y Azure Pipelines:puede vincular canalizaciones de compilación desde cualquiera de los proyectos de Azure Pipelines o TFS. Puede vincular varias canalizaciones de compilación y especificar valores predeterminados para cada una de ellas. Puede configurar desencadenadores de implementación continua en varios orígenes de compilación. Cuando se complete cualquiera de las compilaciones, desencadenará la creación de una versión.

Las siguientes características están disponibles cuando se usan Azure Pipelines orígenes:

Orígenes de artefactos: TFVC, Git y GitHub

Hay escenarios en los que puede que desee consumir artefactos almacenados en un sistema de control de versiones directamente, sin pasarlos a través de una canalización de compilación. Por ejemplo:

• Está desarrollando una aplicación PHP o JavaScript que no requiere una canalización de compilación explícita.

• Las configuraciones de varias fases se administran en repositorios de control de versiones diferentes y quiere consumir estos archivos de configuración directamente desde el control de versiones como parte de la canalización de implementación.

• Administre la infraestructura y la configuración como código (por ejemplo, Azure Resource Manager plantillas) y desea administrar estos archivos en un repositorio de control de versiones.

Dado que puede configurar varios orígenes de artefactos en una única canalización de versión, puede vincular tanto una canalización de compilación que genera los archivos binarios de la aplicación como un repositorio de control de versiones que almacena los archivos de configuración en la misma canalización y usar los dos conjuntos de artefactos juntos durante la implementación.

Azure Pipelines integra con repositorios de Control de versiones de Team Foundation (TFVC), repositorios de Git y GitHub repositorios.

Puede vincular una canalización de versión a cualquiera de los repositorios de Git o TFVC en cualquiera de los proyectos de la colección (necesitará acceso de lectura a estos repositorios). No se requiere ninguna configuración adicional al implementar artefactos de control de versiones dentro de la misma colección.

Al vincular un repositorio gito GitHub y seleccionar una rama, puede editar las propiedades predeterminadas de los tipos de artefacto una vez guardado el artefacto. Esto es especialmente útil en escenarios donde cambia la rama de la versión estable del artefacto y las versiones de entrega continua deben usar esta rama para obtener versiones más recientes del artefacto. También puede especificar detalles de la desprotección, como si los submódulos de finalización de la compra y los archivos con seguimiento LFS, y la profundidad de captura superficial.

Al vincular una rama de TFVC,puede especificar el conjunto de cambios que se va a implementar al crear una versión.

Las siguientes características están disponibles al usar TFVC, Git y GitHub orígenes:

Orígenes de artefactos: Jenkins

Para consumir artefactos de Jenkins, debe crear una conexión de servicio con credenciales para conectarse al servidor Jenkins. Para más información, consulte Conexiones de servicio yConexión de servicio de Jenkins. A continuación, puede vincular un proyecto de Jenkins a una canalización de versión. El proyecto de Jenkins debe configurarse con una acción posterior a la compilación para publicar los artefactos.

Las siguientes características están disponibles cuando se usan orígenes de Jenkins: