Canalizaciones de versión clásicas

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019

Las canalizaciones de versión clásicas proporcionan a los desarrolladores un marco para implementar aplicaciones en varios entornos de forma eficiente y segura. Con las canalizaciones de versión clásicas, puede automatizar los procesos de prueba e implementación, configurar estrategias de implementación flexibles, incorporar flujos de trabajo de aprobación y garantizar transiciones de aplicación fluidas en varias fases.

¿Cómo funcionan las canalizaciones de versión?

Azure Pipelines ejecuta los pasos siguientes como parte de cada implementación:

1. Aprobación anterior a la implementación:

   Cuando se desencadena una nueva solicitud de implementación, Azure Pipelines comprueba si es necesaria una aprobación previa a la implementación antes de implementar una versión en una fase. Si se requiere aprobación, envía notificaciones por correo electrónico a los aprobadores relevantes.

2. Puesta en cola del trabajo de implementación:

   Azure Pipelines programa el trabajo de implementación en un agente disponible.

3. Selección de agente:

   Un agente disponible recoge el trabajo de implementación. Una canalización de versión se puede configurar para seleccionar dinámicamente un agente adecuado durante el runtime.

4. Descarga de artefactos:

   El agente recupera y descarga todos los artefactos especificados en la versión.

5. Ejecución de las tareas de implementación:

   El agente ejecuta todas las tareas del trabajo de implementación.

6. Generación de registros de progreso::

   El agente genera registros completos para cada paso de implementación y los envía de vuelta a Azure Pipelines.

7. Aprobación posterior a la implementación:

   Una vez finalizada la implementación en una fase, Azure Pipelines comprueba si es necesaria una aprobación posterior a la implementación para esa fase determinada. Si no se necesita ninguna aprobación o una vez que se obtiene una aprobación obligatoria, pasa a iniciar la implementación en la siguiente fase.

Modelo de implementación

Las canalizaciones de versión de Azure admiten una amplia gama de orígenes de artefactos, como Jenkins, Azure Artifacts y Team City. En el ejemplo siguiente se muestra un modelo de implementación mediante canalizaciones de versión de Azure:

En el ejemplo siguiente, la canalización consta de dos artefactos de compilación que se originan en canalizaciones de compilación independientes. La aplicación se implementa primero en una fase de desarrollo y, a continuación, se bifurca en dos fases de control de calidad en paralelo. Si la implementación se realiza correctamente en ambas fases de control de calidad, la aplicación se implementará en el anillo de producción 1 y, a continuación, en el anillo de producción 2. Cada anillo de producción representa varias instancias de la misma aplicación web implementadas en diferentes ubicaciones de todo el mundo.

Preguntas más frecuentes

P: ¿Cómo puedo editar variables en tiempo de lanzamiento?

R: En la pestaña Variables de la canalización de versión, seleccione la casilla Configurable al crear la versión para las variables que desea modificar cuando se pone en cola una versión.

Posteriormente, al generar una nueva versión, tiene la capacidad de modificar los valores de esas variables.

P: ¿Cuándo sería más adecuado modificar una versión en lugar de la canalización que la define?

R: Puede editar las aprobaciones, las tareas y las variables de una instancia de versión. Sin embargo, estas modificaciones solo se aplicarán a esa instancia. Si quiere que los cambios se apliquen a todas las versiones futuras, edite la canalización de versión en su lugar.

P: ¿Cuáles son los escenarios en los que la característica "abandonar una versión" es útil?

R: Si no tiene previsto reutilizar la versión o desea impedir que se use, puede abandonar la versión como se indica a continuación: Canalizaciones> (...) >Abandonar. No puede abandonar una versión cuando una implementación está en curso, primero debe cancelar la implementación.

P: ¿Cómo puedo administrar los nombres de las nuevas versiones?

R: La convención de nomenclatura predeterminada para las canalizaciones de versión es la numeración secuencial, donde las versiones se denominan Versión-1, Versión-2, etc. Sin embargo, tiene la flexibilidad de personalizar el esquema de nomenclatura modificando la máscara de formato de nombre de versión. En la pestaña Opciones de la canalización de versión, vaya a la página General y ajuste la propiedad Formato de nombre de la versión para adaptarlo a sus preferencias.

Al especificar la máscara de formato, puede usar las siguientes variables predefinidas. Ejemplo: El siguiente formato de nombre de versión: Release $(Rev:rrr) para la compilación $(Build.BuildNumber) $(Build.DefinitionName) creará la siguiente versión: Release 002 para la compilación 20170213.2 MySampleAppBuild.

Variable	Descripción
Rev: rr	Número incrementado automáticamente con al menos el número de dígitos especificado.
Date / Date: MMddyy	Fecha actual, con el formato predeterminado MMddAA. Se admiten las combinaciones de M/MM/MMM/MMMM, d/dd/ddd/dddd, a/aa/aaa/aaaa, h/hh/H/HH, m/mm, s/ss.
System.TeamProject	Nombre del proyecto al que pertenece la compilación.
Release.ReleaseId	Identificador de la versión, que es único en todas las versiones del proyecto.
Release.DefinitionName	Nombre de la canalización de versión a la que pertenece la versión actual.
Build.BuildNumber	Número de la compilación incluida en la versión. Si una versión tiene varias compilaciones, es el número de la compilación principal.
Build.DefinitionName	Nombre de canalización de la compilación incluida en la versión. Si una versión tiene varias compilaciones, es el nombre de canalización de la compilación principal.
Artifact.ArtifactType	Tipo del origen del artefacto vinculado con la versión. Por ejemplo, puede ser Azure Pipelines o Jenkins.
Build.SourceBranch	Rama del origen del artefacto principal. En el caso de GIT, este es el formulario main si la rama es refs/heads/main. Para Control de versiones de Team Foundation, es el formulario branch si la ruta de acceso del servidor raíz para el área de trabajo es $/teamproject/branch. Esta variable no está establecida para Jenkins u otros orígenes de artefacto.
Variable personalizada	Valor de una propiedad de configuración global definida en la canalización de versión. Puede actualizar el nombre de la versión con variables personalizadas mediante los comandos de registro de versión.

P: ¿Cómo puedo definir el período de retención para las versiones?

R: Consulte directivas de retención para obtener información sobre cómo configurar directivas de retención para las canalizaciones de versión.

Artículos relacionados

• Implementación de artefactos de solicitud de incorporación de cambios
• Implementar desde varias ramas
• Configuración de una canalización de versión administrada en varias fases.