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:
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.
Puesta en cola del trabajo de implementación:
Azure Pipelines programa el trabajo de implementación en un agente disponible.
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.
Descarga de artefactos:
El agente recupera y descarga todos los artefactos especificados en la versión.
Ejecución de las tareas de implementación:
El agente ejecuta todas las tareas del trabajo de implementación.
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.
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.
Versiones frente a implementaciones
Una versión es una construcción que contiene un conjunto con de artefactos con versión especificado en una canalización de CI/CD. Incluye una instantánea de toda la información necesaria para llevar a cabo todas las tareas y acciones de la canalización de versión, como fases, tareas, directivas, como desencadenadores y aprobadores, y opciones de implementación. Puede haber varias versiones de una misma canalización de versión. Se almacena información sobre cada una de ellas y se muestra en Azure Pipelines durante el período de retención especificado.
Una implementación es la acción de ejecutar las tareas de una fase, que pueden incluir la ejecución de pruebas automatizadas, la implementación de artefactos de compilación y cualquier otra acción especificada para esa fase. Al iniciar una versión, se inicia cada implementación según la configuración y las directivas definidas en la canalización de la versión original. Puede haber varias implementaciones de cada versión, incluso para una fase. Cuando se produce un error en la implementación de una versión para una fase, puede volver a implementar la misma versión en esa fase. Para volver a implementar una versión, simplemente vaya a la versión que quiere implementar y seleccione Implementar.
En el diagrama siguiente se muestra la relación entre versiones, canalizaciones de versión e implementaciones.
Preguntas más frecuentes
P: ¿Por qué no se desencadenó mi implementación?
R: La creación de una canalización de versión no inicia automáticamente una implementación. Estas son algunas razones por las que esto puede ocurrir:
Desencadenadores de implementación: los desencadenadores de implementación definidos pueden hacer que la implementación se detenga. Esto puede ocurrir con desencadenadores programados o cuando se produce un retraso hasta que se complete la implementación en otra fase.
Directivas de puesta en cola: estas directivas dictan el orden de ejecución y cuándo se ponen en cola las versiones para la implementación.
Aprobaciones previas a la implementación o puertas: las fases específicas pueden requerir aprobaciones o puertas previas a la implementación, lo que impide la implementación hasta que se cumplan todas las condiciones definidas.
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.