Restricción de las transiciones de estado del elemento de trabajo

Después de varios sprints en versión preliminar, ahora anunciamos la versión general de las reglas de restricción de transición de estado a todos los clientes como parte de la actualización sprint 172.

Consulte la lista de características siguiente para obtener más información.

Características

Azure Boards

• Reglas de restricción de transición de estado
• Copiar elemento de trabajo para copiar elementos secundarios
• Reglas mejoradas para campos activados y resueltos
• Tipos de elementos de trabajo del sistema en trabajos pendientes y paneles (versión preliminar privada)

Azure Pipelines

• Directiva de bloqueo de implementación exclusiva
• Fases filtra los desencadenadores de recursos de canalización
• Desencadenadores basados en webhook genéricos para canalizaciones YAML
• Problemas de compatibilidad y rastreabilidad de los desencadenadores de recursos DE YAML
• Banner para incidentes de sitio activo que afectan a las canalizaciones

Azure Artifacts

• Capacidad de crear fuentes con ámbito de organización a partir de la interfaz de usuario

Azure Boards

Reglas de restricción de transición de estado

Después de varios sprints de versión preliminar privada, las reglas de restricción de transición de estado ahora están disponibles con carácter general para todos los clientes. Esta nueva regla de tipo de elemento de trabajo permite restringir que los elementos de trabajo se muevan de un estado a otro. Por ejemplo, puede restringir que los errores vayan de Nuevo a Resuelto. En su lugar, deben ir de Nuevo -> Activo -> Resuelto

También puede crear una regla para restringir las transiciones de estado por pertenencia a grupos. Por ejemplo, solo los usuarios del grupo "Aprobadores" pueden mover casos de usuario de New -> Approved.

Copiar elemento de trabajo para copiar elementos secundarios

Una de las principales características solicitadas para Azure Boards es la capacidad de copiar un elemento de trabajo que también copia los elementos de trabajo secundarios. En este sprint, hemos agregado una nueva opción a "Incluir elementos de trabajo secundarios" al cuadro de diálogo copiar elemento de trabajo. Cuando se selecciona, esta opción copiará el elemento de trabajo y copiará todos los elementos de trabajo secundarios (hasta 100).

Reglas mejoradas para campos activados y resueltos

Hasta ahora, las reglas de Activated By, Activated Date, Resolved By y Resolved Date han sido un misterio. Solo se establecen para los tipos de elementos de trabajo del sistema y son específicos del valor de estado de "Activo" y "Resuelto". En sprint 172 cambiamos la lógica para que estas reglas ya no sean para un estado específico. En su lugar, se desencadenan mediante la categoría (categoría de estado) en la que reside el estado. Por ejemplo, supongamos que tiene un estado personalizado de "Necesidades de pruebas" en la categoría Resuelto. Cuando el elemento de trabajo cambia de "Activo" a "Necesita pruebas", se desencadenan las reglas De fecha resuelta por y Resuelta.

Esto permite a los clientes crear cualquier valor de estado personalizado y seguir generando los campos Activated By, Activated Date, Resolved By y Resolved Date , sin necesidad de usar reglas personalizadas.

Tipos de elementos de trabajo del sistema en trabajos pendientes y paneles (versión preliminar privada)

Desde el inicio del modelo de proceso de herencia, se han excluido varios tipos de elementos de trabajo que se han agregado a paneles y trabajos pendientes. Estos tipos de elementos de trabajo incluyen:

A partir de este sprint, estamos permitiendo una versión preliminar privada para aquellos clientes que quieran permitir que estos tipos de elementos de trabajo estén disponibles en cualquier nivel de trabajo pendiente.

Si está interesado en obtener una vista previa de esta característica, envíenos un correo electrónico con el nombre de su organización y podemos proporcionarle acceso.

Azure Pipelines

Directiva de bloqueo de implementación exclusiva

Con esta actualización, puede asegurarse de que solo se implementa una sola ejecución en un entorno a la vez. Al elegir la comprobación "Bloqueo exclusivo" en un entorno, solo se realizará una ejecución. Las ejecuciones posteriores que quieran implementar en ese entorno se pausarán. Una vez completada la ejecución con el bloqueo exclusivo, la ejecución más reciente continuará. Las ejecuciones intermedias se cancelarán.

Fases filtra los desencadenadores de recursos de canalización

En este sprint, se ha agregado compatibilidad con "fases" como filtro para los recursos de canalización en YAML. Con este filtro, no es necesario esperar a que se complete toda la canalización de CI para desencadenar la canalización de CD. Ahora puede optar por desencadenar la canalización de CD tras la finalización de una fase específica de la canalización de CI.

resources:
  pipelines:
  - pipeline: MyCIAlias  
    project: Fabrikam  
    source: Farbrikam-CI  
    trigger:    
      stages:            ### This stage filter is used when evaluating conditions for triggering your CD pipeline
      - PreProduction    ### stages are AND'ed. On successful completion of all the stages provided, your CD pipeline will be triggered. 
      - Production

Cuando las fases proporcionadas en el filtro de desencadenador se completan correctamente en la canalización de CI, se desencadena automáticamente una nueva ejecución para la canalización de CD.

Desencadenadores basados en webhook genéricos para canalizaciones YAML

En la actualidad, tenemos varios recursos (como canalizaciones, contenedores, compilación y paquetes) a través de los cuales puede consumir artefactos y habilitar desencadenadores automatizados. Sin embargo, hasta ahora no se pudo automatizar el proceso de implementación en función de otros eventos o servicios externos. En esta versión, presentamos compatibilidad con desencadenadores de webhook en canalizaciones YAML para habilitar la integración de la automatización de canalizaciones con cualquier servicio externo. Puede suscribirse a cualquier evento externo a través de sus webhooks (GitHub, GitHub Enterprise, Nexus, Artifactory, etc.) y desencadenar las canalizaciones.

Estos son los pasos para configurar los desencadenadores de webhook:

1. Configure un webhook en el servicio externo. Al crear el webhook, debe proporcionar la siguiente información:

   • Url de solicitud: "https://dev.azure.com/<Organización> de ADO/_apis/public/distributedtask/webhooks/<Nombre> de webHook?api-version=6.0-preview"
   • Secreto: es opcional. Si necesita proteger la carga JSON, proporcione el valor secreto .

2. Cree una nueva conexión de servicio de "Webhook entrante". Se trata de un tipo de conexión de servicio recién introducido que le permitirá definir tres partes importantes de información:

   • Nombre del webhook: el nombre del webhook debe coincidir con el webhook creado en el servicio externo.
   • Encabezado HTTP: el nombre del encabezado HTTP de la solicitud que contiene el valor hash de carga para la comprobación de la solicitud. Por ejemplo, en el caso de GitHub, el encabezado de solicitud será "X-Hub-Signature"
   • Secreto : el secreto se usa para analizar el hash de carga usado para la comprobación de la solicitud entrante (esto es opcional). Si ha usado un secreto para crear el webhook, deberá proporcionar la misma clave secreta.

   

3. En las canalizaciones YAML, se introduce un nuevo tipo de recurso denominado webhooks. Para suscribirse a un evento de webhook, debe definir un recurso de webhook en la canalización y apuntarlo a la conexión del servicio de webhook entrante. También puede definir filtros adicionales en el recurso de webhook en función de los datos de carga JSON para personalizar aún más los desencadenadores de cada canalización y puede consumir los datos de carga en forma de variables en los trabajos.

resources:
  webhooks:
    - webhook: MyWebhookTrigger          ### Webhook alias
      connection: MyWebhookConnection    ### Incoming webhook service connection
      filters:
        - path: repositoryName      ### JSON path in the payload
          value: maven-releases     ### Expected value in the path provided
        - path: action
          value: CREATED
steps:
- task: PowerShell@2
  inputs:
    targetType: 'inline'
    ### JSON payload data is available in the form of ${{ parameters.<WebhookAlias>.<JSONPath>}}
    script: |
      Write-Host ${{ parameters.MyWebhookTrigger.repositoryName}}
      Write-Host ${{ parameters.MyWebhookTrigger.component.group}}

4. Cada vez que la conexión del servicio De webhook entrante recibe un evento de webhook, se desencadenará una nueva ejecución para todas las canalizaciones suscritas al evento de webhook.

Soporte técnico y trazabilidad de los problemas de desencadenadores de recursos YAML

Puede resultar confuso cuando los desencadenadores de canalización no se ejecutan según lo previsto. Para ayudar a comprender mejor esto, hemos agregado un nuevo elemento de menú en la página de definición de canalización denominada "Problemas de desencadenador" donde se muestra información sobre por qué los desencadenadores no se están ejecutando.

Los desencadenadores de recursos pueden no ejecutarse por dos motivos.

1. Si el origen de la conexión de servicio proporcionada no es válido o si hay errores de sintaxis en el desencadenador, el desencadenador no se configurará en absoluto. Se muestran como errores.

2. Si las condiciones del desencadenador no coinciden, el desencadenador no se ejecutará. Siempre que esto ocurra, se mostrará una advertencia para que pueda comprender por qué no se han coinciden las condiciones.

   

Banner para incidentes de sitio activo que afectan a las canalizaciones

Hemos agregado un banner de advertencia a la página canalizaciones para alertar a los usuarios de incidentes en curso en su región, lo que puede afectar a las canalizaciones.

Azure Artifacts

Capacidad de crear fuentes con ámbito de organización a partir de la interfaz de usuario

Estamos devolviendo la capacidad de los clientes de crear y administrar fuentes de ámbito de la organización a través de la interfaz de usuario web para los servicios locales y hospedados.

Ahora puede crear fuentes con ámbito de organización a través de la interfaz de usuario; para ello, vaya a Artefactos:> crear fuente y elija un tipo de fuente dentro del ámbito.

Aunque se recomienda el uso de fuentes con ámbito de proyecto en consonancia con el resto de las ofertas de Azure DevOps, puede crear, administrar y usar fuentes con ámbito de organización a través de la interfaz de usuario y varias API REST. Consulte nuestra documentación de fuentes para obtener más información.

Pasos siguientes

Vaya a Azure DevOps y eche un vistazo.

Cómo enviar sus comentarios

Nos encantaría escuchar lo que piensas sobre estas características. Use el menú de ayuda para notificar un problema o proporcionar una sugerencia.

También puede obtener consejos y sus preguntas respondidas por la comunidad en Stack Overflow.

Gracias,

Aaron Hallberg