Partilhar via

Restringir transições de estado de item de trabalho

  • Artigo

Depois de vários sprints na pré-visualização, estamos agora anunciando o lançamento geral das regras de restrição de transição de estado para todos os clientes como parte da Atualização do Sprint 172.

Confira a lista de recursos abaixo para obter mais informações.

Funcionalidades

Azure Boards

Azure Pipelines

Artefactos do Azure

Azure Boards

Regras de restrição de transição de Estado

Após vários sprints de visualização privada, as regras de restrição de transição de estado agora estão geralmente disponíveis para todos os clientes. Esta nova regra de tipo de item de trabalho permite restringir que os itens de trabalho sejam movidos de um estado para outro. Por exemplo, você pode restringir Bugs de ir de Novo para Resolvido. Em vez disso, eles devem ir de Novo –> Ativo -> Resolvido

Este exemplo restringe Bugs para ir do estado New para Ative, depois para Resolved em vez de ir do estado New para Resolve.

Você também pode criar uma regra para restringir transições de estado por associação ao grupo. Por exemplo, apenas os usuários no grupo "Aprovadores" podem mover histórias de usuários de Novo -> Aprovado.

Copiar item de trabalho para copiar crianças

Um dos principais recursos solicitados para os Painéis do Azure é a capacidade de copiar um item de trabalho que também copia os itens de trabalho filho. Neste sprint, adicionamos uma nova opção para "Incluir itens de trabalho filho" à caixa de diálogo de item de trabalho de cópia. Quando selecionada, esta opção copiará o item de trabalho e copiará todos os itens de trabalho filho (até 100).

Esta página mostra a nova opção nos Painéis do Azure para Incluir itens de trabalho filho em um item de trabalho copiado.

Regras melhoradas para campos ativados e resolvidos

Até agora, as regras para Ativado Por, Data Ativada, Resolvida Por e Data Resolvida têm sido um mistério. Eles são definidos apenas para tipos de item de trabalho do sistema e são específicos para o valor de estado de "Ativo" e "Resolvido". No sprint 172 mudamos a lógica para que essas regras não sejam mais para um estado específico. Em vez disso, eles são acionados pela categoria (categoria de estado) em que o estado reside. Por exemplo, digamos que você tenha um estado personalizado de "Precisa de teste" na categoria Resolvido. Quando o item de trabalho muda de "Ativo" para "Precisa de testes", as regras Resolvido por e Data resolvida são acionadas.

Isso permite que os clientes criem quaisquer valores de estado personalizados e ainda gerem os campos Ativado por, Data ativada, Resolvido por e Data resolvida, sem a necessidade de usar regras personalizadas.

Tipos de item de trabalho do sistema em listas de pendências e quadros (visualização privada)

Desde o início do modelo de processo de herança, vários tipos de item de trabalho foram excluídos de serem adicionados a quadros e listas de pendências. Esses tipos de item de trabalho incluem:

Processo Tipo de Item de Trabalho
Ágil Problema
Scrum Impedimento
CMMI Pedido de Alteração
Problema
Rever
Risco

Iniciando este sprint, estamos permitindo uma visualização privada para os clientes que desejam habilitar esses tipos de itens de trabalho para estar disponível em qualquer nível de lista de pendências.

Use esta página Painéis do Azure para adicionar tipos de item de trabalho excluídos anteriormente aos quadros e listas de pendências.

Se estiver interessado em pré-visualizar esta funcionalidade, envie-nos um e-mail com o nome da sua organização e podemos dar-lhe acesso.

Azure Pipelines

Política exclusiva de bloqueio de implantação

Com essa atualização, você pode garantir que apenas uma única execução seja implantada em um ambiente de cada vez. Ao escolher a verificação "Bloqueio exclusivo" em um ambiente, apenas uma execução continuará. As execuções subsequentes que desejam implantar nesse ambiente serão pausadas. Quando a execução com o bloqueio exclusivo for concluída, a última execução continuará. Todas as execuções intermediárias serão canceladas.

Na página Adicionar verificação, selecione Bloqueio exclusivo para garantir que apenas uma única execução seja implantada em um ambiente de cada vez.

Filtros de estágios para gatilhos de recursos de pipeline

Neste sprint, adicionamos suporte para 'estágios' como um filtro para recursos de pipeline no YAML. Com esse filtro, você não precisa esperar que todo o pipeline de CI seja concluído para acionar o pipeline de CD. Agora você pode optar por acionar o pipeline de CD após a conclusão de um estágio específico no pipeline 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

Quando os estágios fornecidos no filtro de gatilho são concluídos com êxito no pipeline de CI, uma nova execução é automaticamente acionada para o pipeline de CD.

Gatilhos genéricos baseados em webhook para pipelines YAML

Hoje, temos vários recursos (como pipelines, contêineres, compilação e pacotes) através dos quais você pode consumir artefatos e habilitar gatilhos automatizados. Até agora, no entanto, você não podia automatizar seu processo de implantação com base em outros eventos ou serviços externos. Nesta versão, estamos introduzindo o suporte a gatilhos de webhook em pipelines YAML para permitir a integração da automação de pipeline com qualquer serviço externo. Você pode se inscrever em quaisquer eventos externos através de seus webhooks (GitHub, GitHub Enterprise, Nexus, Artifactory, etc.) e acionar seus pipelines.

Aqui estão as etapas para configurar os gatilhos do webhook:

  1. Configure um webhook no seu serviço externo. Ao criar seu webhook, você precisa fornecer as seguintes informações:

    • URL da solicitação - "https://dev.azure.com/<ADO Organization>/_apis/public/distributedtask/webhooks/<WebHook Name>?api-version=6.0-preview"
    • Segredo - Isto é opcional. Se você precisar proteger sua carga JSON útil, forneça o valor Secret

  2. Crie uma nova conexão de serviço "Incoming Webhook". Este é um Tipo de Conexão de Serviço recém-introduzido que permitirá definir três informações importantes:

    • Nome do Webhook: O nome do webhook deve corresponder ao webhook criado no seu serviço externo.
    • Cabeçalho HTTP - O nome do cabeçalho HTTP na solicitação que contém o valor de hash da carga útil para verificação da solicitação. Por exemplo, no caso do GitHub, o cabeçalho da solicitação será "X-Hub-Signature"
    • Segredo - O segredo é usado para analisar o hash de carga útil usado para verificação da solicitação de entrada (isso é opcional). Se você usou um segredo na criação de seu webhook, você precisará fornecer a mesma chave secreta

    Na página Editar conexão de serviço, configure gatilhos de webhook.

  3. Um novo tipo de recurso chamado webhooks é introduzido em pipelines YAML. Para assinar um evento webhook, você precisa definir um recurso webhook em seu pipeline e apontá-lo para a conexão de serviço webhook de entrada. Você também pode definir filtros adicionais no recurso webhook com base nos dados de carga JSON para personalizar ainda mais os gatilhos para cada pipeline, e você pode consumir os dados de carga útil na forma de variáveis em seus trabalhos.

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}}
  1. Sempre que um evento webhook é recebido pela conexão do serviço Webhook de entrada, uma nova execução será acionada para todos os pipelines inscritos no evento webhook.

Suporte e rastreabilidade de problemas de gatilho de recursos YAML

Pode ser confuso quando os gatilhos de pipeline não são executados como você espera. Para ajudar a entender melhor isso, adicionamos um novo item de menu na página de definição de pipeline chamado 'Problemas de gatilho', onde são exibidas informações sobre por que os gatilhos não estão sendo executados.

Os gatilhos de recursos podem falhar na execução por dois motivos.

  1. Se a origem da conexão de serviço fornecida for inválida ou se houver erros de sintaxe no gatilho, o gatilho não será configurado. Estes são apresentados como erros.

  2. Se as condições do gatilho não forem correspondidas, o gatilho não será executado. Sempre que isso ocorrer, um aviso será exibido para que você possa entender por que as condições não foram correspondidas.

    Esta página de definição de pipeline chamada Problemas de gatilho exibe informações sobre por que os gatilhos não estão em execução.

Adicionamos um banner de aviso à página de pipelines para alertar os usuários sobre incidentes contínuos em sua região, que podem afetar seus pipelines.

Artefactos do Azure

Capacidade de criar feeds com escopo organizacional a partir da interface do usuário

Estamos trazendo de volta a capacidade dos clientes de criar e gerenciar feeds com escopo da organização por meio da interface do usuário da Web para serviços locais e hospedados.

Agora você pode criar feeds com escopo organizacional por meio da interface do usuário, indo para Artefatos -> Criar feed e escolhendo um tipo de feed dentro do escopo.

Crie feeds com escopo da organização selecionando Artefatos, depois Criar Feed e selecionando um tipo de feed dentro do Escopo.

Embora recomendemos o uso de feeds com escopo de projeto em alinhamento com o restante das ofertas de DevOps do Azure, você pode criar, gerenciar e usar novamente feeds com escopo da organização por meio da interface do usuário e de várias APIs REST. Consulte a nossa documentação de feeds para obter mais informações.

Próximos passos

Nota

Esses recursos serão lançados nas próximas duas a três semanas.

Vá até o Azure DevOps e dê uma olhada.

Ir para Azure DevOps

Como fornecer feedback

Gostaríamos muito de ouvir o que você pensa sobre esses recursos. Use o menu Ajuda para relatar um problema ou fornecer uma sugestão.

Faça uma sugestão

Você também pode obter conselhos e suas perguntas respondidas pela comunidade no Stack Overflow.

Obrigado,

Aaron Hallberg