Canalizaciones de versión
Azure Pipelines | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 - TFS 2015
Nota:
En Microsoft Team Foundation Server (TFS) 2018 y versiones anteriores, las canalizaciones de compilación y versión se denominan definiciones, las ejecuciones se denominan compilaciones, las conexiones de servicio se denominan puntos de conexión de servicio, las fases se denominan entornos y los trabajos se denominan fases.
Nota:
En este artículo se describen las canalizaciones de versión clásicas. Si desea usar YAML para crear canalizaciones de CI/CD, consulte Creación de la primera canalización.
Las canalizaciones de versión en Azure Pipelines ayudan a su equipo a ofrecer continuamente software a sus clientes a un ritmo más rápido y a un menor riesgo. Puede automatizar completamente las pruebas y la entrega del software en varias fases hasta llegar a la producción. O bien, configure procesos semiautomatizados con aprobaciones e implementaciones a petición.
Consulte Versiones en Azure Pipelines para conocer las versiones e implementaciones y vea el siguiente vídeo para ver las canalizaciones de versión en acción.
¿Cómo funcionan las canalizaciones de versión?
Las canalizaciones de versión almacenan los datos de las canalizaciones, las fases, las tareas, las versiones y las implementaciones en Azure Pipelines.
Azure Pipelines ejecuta los pasos siguientes como parte de cada implementación:
Aprobación previa 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 es necesario, envía notificaciones por correo electrónico a los aprobadores adecuados.
Puesta en cola del trabajo de implementación: Azure Pipelines programa el trabajo de implementación en un agente de automatización disponible. Un agente es un elemento de software que puede ejecutar tareas en la implementación.
Selección de agente: un agente de automatización recoge el trabajo. Los agentes para las canalizaciones de versión son exactamente iguales que los agentes que ejecutan las compilaciones en Azure Pipelines. Una canalización de versión puede contener valores para seleccionar un agente adecuado en el entorno de ejecución.
Descarga de artefactos: el agente descarga todos los artefactos especificados en esa versión, siempre que no haya optado por omitir la descarga. El agente comprende actualmente dos tipos de artefactos: artefactos de Azure Pipelines y artefactos de Jenkins.
Ejecución de las tareas de implementación: el agente ejecuta todas las tareas del trabajo de implementación para implementar la aplicación en los servidores de destino de una fase.
Generación de registros de progreso: el agente crea registros detallados para cada paso mientras se ejecuta la implementación, y vuelve a enviar estos registros a Azure Pipelines.
Aprobación posterior a la implementación: cuando se complete la implementación en una fase, Azure Pipelines comprobará si se requiere una aprobación posterior a la implementación para esa fase. Si no se requiere ninguna aprobación, o al completar una aprobación requerida, se procede a desencadenar la implementación en la siguiente etapa.
Las canalizaciones de versión y las canalizaciones de compilación tienen IU independientes. Las principales diferencias en las canalizaciones son la compatibilidad con las canalizaciones de versión de los distintos tipos de desencadenadores y la compatibilidad con aprobaciones y puertas.
¿Cómo se usa una canalización de versión?
Empiece a usar las versiones de Azure Pipelines mediante la creación de una canalización de versión para la aplicación. Para crear una canalización de versión, debe especificar los artefactos que componen la aplicación y la canalización de versión.
Un artefacto es un componente que se puede implementar de la aplicación. Normalmente se genera a través de una integración continua o una canalización de compilación. Las versiones de Azure Pipelines pueden implementar artefactos generados por una amplia gama de orígenes de artefactos, como una compilación de Azure Pipelines, Jenkins o Team City.
Defina la canalización de versión mediante fases y establezca restricciones para las implementaciones dentro o fuera de una fase mediante aprobaciones. Defina la automatización en cada fase mediante trabajos y tareas. Use variables para generalizar la automatización y desencadenadores para controlar cuándo se deben iniciar automáticamente las implementaciones.
Vea el ejemplo siguiente de una canalización de versión que se puede modelar a través de una canalización de versión:
En este ejemplo, se crea una versión de un sitio web recopilando versiones específicas de dos compilaciones (artefactos), cada una de una canalización de compilación diferente. La versió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 pasa correctamente por ambas fases de control de calidad, la versión se implementa en el anillo 1 de producción y luego en el anillo 2 de producción. Cada anillo de producción representa varias instancias del mismo sitio web implementadas en diferentes ubicaciones de todo el mundo.
Vea el siguiente ejemplo de cómo se puede modelar la automatización de la implementación en una fase:
En este ejemplo, se usa un trabajo para implementar la aplicación en sitios web de todo el mundo en paralelo en el anillo 1 de producción. Después de que todas las implementaciones se lleven a cabo correctamente, se usa un segundo trabajo para cambiar el tráfico de la versión anterior a la versión más reciente.
Nota:
TFS 2015: los trabajos y las implementaciones de bifurcación/unión no están disponibles en TFS 2015.
Siguiente:
Utilice los siguientes tutoriales para aprender lo siguiente:
Configuración de una canalización de versión administrada en varias fases.
Administración de implementaciones mediante aprobaciones y puertas.
¿Qué es una versión en borrador?
Las versiones de borrador están en desuso en Azure Pipelines porque puede cambiar las variables mientras crea la versión.
La creación de una versión de borrador permite editar algunas opciones de configuración de la versión y de las tareas, en función de los permisos de rol, antes de iniciar la implementación. Los cambios solo se aplican a esa versión y no afectan a la configuración de la canalización original.
Cree una versión de borrador con el vínculo de puntos suspensivos "..." en la lista de versiones:
... o en la lista desplegable Versión de la página de definición de canalizaciones:
Cuando termine de editar la versión en borrador, elija Iniciar en la barra de herramientas de la versión en borrador.
¿Cómo puedo especificar las variables que deseo editar cuando se crea una versión?
En la pestaña Variables de una canalización de versión, cuando agregue nuevas variables, establezca Configurable al crear la versión para las variables que desea editar cuando se crea y se pone en cola una versión.
A continuación, cuando se crea una nueva versión, se pueden editar los valores de estas variables.
¿Cómo se integra y notifica el estado de la versión?
Con las integraciones de canalizaciones de versión, puede notificar el estado de la implementación a varios orígenes, como el host del repositorio, los elementos de trabajo (vínculos o implementaciones) o las incidencias de Jira.
Para configurar las integraciones de canalización de versión, seleccione la pestaña Opciones y, a continuación, seleccione Integraciones en la definición de canalización de versión.
Notificación del estado de la implementación al host del repositorio
Si el código fuente está en Azure Repos, esta opción muestra un distintivo de estado en las páginas de Azure Repos. La notificación indica dónde se ha implementado la confirmación específica y si la implementación se está superando o no. De forma predeterminada, se publica un estado de implementación para todas las fases de la canalización de versión. También puede seleccionar fases específicas para mostrar el estado de implementación.
El estado de implementación se muestra en las siguientes áreas de Azure Repos:
Archivos: indica el estado de la implementación más reciente de la rama seleccionada.
Confirmaciones: indica el estado de implementación de cada confirmación (requiere que se habilite el desencadenador de integración continua).
Ramas: indica el estado de la implementación más reciente de cada rama.
Nota:
Si el código fuente no está en Azure Repos, puede usar la característica Habilitar el distintivo de estado de implementación para mostrar el estado de implementación en repositorios externos.
Notificar estado de implementación al trabajo
Seleccione esta opción si quiere vincular la canalización de versión a los elementos de trabajo. El estado de implementación se mostrará en la pestaña Vínculos del elemento de trabajo.
Notificación del estado de implementación a Boards
Seleccione esta opción si quiere vincular la canalización de versión a los elementos de trabajo y mostrar el estado de implementación en la pestaña Detalles del elemento de trabajo.
Habilitar la notificación de estado de implementación
Seleccione esta opción si quiere ver el estado de la implementación en un sitio web externo. Puede copiar el distintivo de fase y agregarlo al sitio web para ver el estado de implementación:
Seleccione Habilitar la notificación de estado de la implementación.
Seleccione las fases para las que quiera mostrar el estado. De forma predeterminada, se seleccionan todas las fases.
Copie la URL del distintivo y agréguela a su sitio web o archivo Léame de GitHub para mostrar el estado de la implementación.
Notificación del estado de implementación a Jira
Seleccione esta opción si quiere vincular la canalización de versión a incidencias de Jira. Debe instalar Azure Pipelines for Jira y conectar su organización de Azure DevOps con su cuenta de Jira. Consulte el tutorial de integración de Jira para obtener más detalles.
¿Cuándo debo editar una versión en lugar de la canalización que la define?
Puede editar las aprobaciones, las tareas y las variables de una versión implementada previamente. Hágalo en lugar de editar estos valores en la canalización desde la que se creó la versión. Sin embargo, estas modificaciones solo se aplican a la versión que se genera al volver a implementar los artefactos. Si desea que las ediciones se apliquen a todas las versiones e implementaciones futuras, elija la opción para editar la canalización de versión en su lugar.
¿Cuándo y por qué debo abandonar una versión?
Después de crear una versión, puede volver a implementar los artefactos en las fases definidas en esa versión. Esto resulta útil si desea realizar versiones manuales periódicas o configurar un desencadenador de fase de integración continua que vuelva a implementar los artefactos con esta versión.
Si no tiene previsto reutilizar la versión o desea evitar que se use para volver a implementar los artefactos, puede abandonar la versión mediante el menú contextual que se abre desde el icono de puntos suspensivos ( ... ) en la vista Canalización de la canalización.
No puede abandonar una versión cuando una implementación está en curso, primero debe cancelar la implementación.
¿Cómo puedo enviar resúmenes de versión por correo electrónico?
Una vez que se desencadena y completa una versión, es posible que desee enviar por correo electrónico el resumen a las partes interesadas. Use la opción Enviar correo electrónico en el menú que se abre desde el icono de puntos suspensivos ( ... ) en la vista Canalización de la canalización.
En la ventana Enviar correo electrónico de resumen de la versión, puede personalizar aún más la información enviada en el correo electrónico seleccionando solo determinadas secciones del resumen de la versión.
¿Cómo puedo administrar los nombres de las nuevas versiones?
De forma predeterminada, los nombres de las versiones de una canalización de versión se numeran secuencialmente. La primera versión se denomina Release-1, la versión siguiente es Release-2, etc. Puede cambiar este esquema de nomenclatura editando la máscara de formato del nombre de la versión. En la pestaña Opciones de una canalización de versión, edite la propiedad Formato del nombre de la versión en la página General.
Al especificar la máscara de formato, puede usar las siguientes variables predefinidas.
| 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. |
Por ejemplo, el formato de nombre de versión crea versiones con nombres como Release $(Rev:rrr) for build $(Build.BuildNumber) $(Build.DefinitionName)Release $(Rev:rrr) for build $(Build.BuildNumber) $(Build.DefinitionName)
¿Cómo puedo especificar el período de retención para las versiones?
Puede personalizar el tiempo que se deben conservar las versiones de esta canalización. Para obtener más información, consulte la retención de versiones.
¿Cómo puedo usar y administrar el historial de versiones?
Cada vez que guarda una canalización de versión, Azure Pipelines mantiene una copia de los cambios. Esta copia permite comparar los cambios en un punto posterior, especialmente cuando se depura un error de implementación.
¿Cómo puedo configurarlo para vincular automáticamente el nuevo trabajo en una compilación?
Cuando se establece la trazabilidad entre los elementos de trabajo y las compilaciones y versiones, existen los dos aspectos siguientes:
- Enumere los elementos de trabajo que se compilaron recientemente como parte de una compilación. Puede encontrarlos si está examinando una instancia de compilación.
- Enumere las compilaciones en las que se compiló este elemento de trabajo. Puede encontrar la lista en la sección "Desarrollo" de un formulario de elemento de trabajo. El valor "Vincular automáticamente nuevo trabajo en esta compilación" no tiene nada que ver con la forma en que se calcula el primer elemento de la lista con viñetas. Solo influye en cómo se calcula el segundo elemento de la lista con viñetas.
El cálculo del primer punto es así para una compilación: supongamos, por ejemplo, que has iniciado una nueva compilación. Sea cual sea la configuración, calculamos una lista de las nuevas confirmaciones para la compilación. Llevamos a cabo las tareas siguientes:
- Encontramos la confirmación C2 que se va a compilar ahora.
- Encontramos la confirmación C1 que se compiló en la última compilación correcta de la misma rama (Build.SourceBranch).
- Encontramos todas las confirmaciones entre C1 y C2 (en el árbol de confirmación).
Podría ocurrir que no haya ninguna última compilación correcta conocida en la misma rama. Por ejemplo, cuando se ejecuta una compilación por primera vez en una rama, o cuando se han eliminado todas las compilaciones anteriores de una rama (posiblemente a través de directivas de retención). La lista puede ser larga en estos casos.
Una vez que tenemos la lista de confirmaciones, se enumeran todos los elementos de trabajo asociados a cada una de las confirmaciones. Esta es la lista que se muestra en una compilación.
Comience ahora.
Complete los pasos siguientes:
Configuración de una canalización de versión administrada en varias fases.
Administración de implementaciones mediante aprobaciones y puertas