Restringir transições de estado do item de trabalho

Depois de vários sprints em versão prévia, agora estamos 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.

Recursos

Azure Boards

• Regras de restrição de transição de estado
• Copiar item de trabalho para copiar filhos
• Regras aprimoradas para campos ativados e resolvidos
• Tipos de item de trabalho do sistema em listas de pendências e quadros (visualização privada)

Azure Pipelines

• Política de bloqueio de implantação exclusiva
• Filtros de estágios para gatilhos de recursos de pipeline
• Gatilhos genéricos baseados em webhook para pipelines YAML
• Suporte e rastreabilidade de problemas de gatilho de recurso YAML
• Banner para incidentes de site ativo que afetam pipelines

Azure Artifacts

• Capacidade de criar feeds no escopo da organização a partir da interface do usuário

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 disponíveis para todos os clientes. Essa nova regra de tipo de item de trabalho permite que você restrinja que os itens de trabalho sejam movidos de um estado para outro. Por exemplo, você pode impedir que os bugs passem de Novo para Resolvido. Em vez disso, eles devem ir de Novo -> Ativo -> Resolvido

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

Copiar item de trabalho para copiar filhos

Um dos principais recursos solicitados para Azure Boards é 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 copiar item de trabalho. Quando selecionada, essa opção copiará o item de trabalho e copiará todos os itens de trabalho filho (até 100).

Regras aprimoradas para campos ativados e resolvidos

Até agora, as regras para Ativado por, Data de Ativação, Resolvido por e Data de Resolução 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 Teste", as regras Resolvido por e Data Resolvida são disparadas.

Isso permite que os clientes criem valores de estado personalizados e ainda gerem os campos Ativado por, Data de Ativação, Resolvido por e Data de Resolução, 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
Agile	Problema
Scrum	Impedimento
CMMI	Alterar pedido
	Problema
	Revisão
	Risco

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

Se você estiver interessado em visualizar esse recurso, envie-nos um e-mail com o nome da sua organização e podemos lhe dar acesso.

Azure Pipelines

Política de bloqueio de implantação exclusiva

Com essa atualização, você pode garantir que apenas uma única execução seja implantada em um ambiente por 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. Assim que a execução com o bloqueio exclusivo for concluída, a última execução continuará. Quaisquer execuções intermediárias serão canceladas.

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 disparar o pipeline de CD. Agora você pode optar por disparar seu pipeline de CD após a conclusão de um estágio específico em seu 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 é disparada automaticamente para o pipeline de CD.

Gatilhos genéricos baseados em webhook para pipelines YAML

Hoje, temos vários recursos (como pipelines, contêineres, build e pacotes) por meio 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 ao gatilho de webhook em pipelines YAML para permitir a integração da automação de pipeline com qualquer serviço externo. Você pode assinar qualquer evento externo por meio de seus webhooks (GitHub, GitHub Enterprise, Nexus, Artifactory etc.) e acionar seus pipelines.

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

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

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

2. Crie uma nova conexão de serviço do "Webhook de Entrada". Este é um Tipo de Conexão de Serviço recém-introduzido que permitirá que você defina 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 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 do webhook, precisará fornecer a mesma chave secreta

   

3. Um novo tipo de recurso chamado webhooks foi introduzido em pipelines YAML. Para assinar um evento de webhook, você precisa definir um recurso de webhook em seu pipeline e apontá-lo para a conexão de serviço de webhook de entrada. Você também pode definir filtros adicionais no recurso de webhook com base nos dados de carga JSON para personalizar ainda mais os gatilhos para cada pipeline e pode consumir os dados de carga 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}}

4. Sempre que um evento de webhook for recebido pela conexão de serviço de Webhook de entrada, uma nova execução será disparada para todos os pipelines inscritos no evento de webhook.

Suporte e rastreabilidade de problemas de gatilho de recurso 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 ao serem executados 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 exibidos 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.

   

Banner para incidentes de site ativo que afetam pipelines

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

Azure Artifacts

Capacidade de criar feeds no escopo da organização a partir da interface do usuário

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

Agora você pode criar feeds no escopo da organização por meio da interface do usuário, acessando Artefatos -> Criar feed e escolhendo um tipo de feed no Escopo.

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

Próximas etapas

Observação

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 o Azure DevOps

Como fornecer comentários

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

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

Obrigada,

Aaron Hallberg