Delen via

Overgangen van werkitemsstatus beperken

  • Artikel

Na verschillende sprints in preview aankondigen we nu de algemene release van regels voor statusovergangsbeperkingen voor alle klanten als onderdeel van de Sprint 172 Update.

Bekijk de onderstaande lijst met functies voor meer informatie.

Functies

Azure Boards

Azure-pipelines

Azure Artifacts

Azure Boards

Beperkingsregels voor statusovergang

Na verschillende sprints van de privé-preview zijn de regels voor statusovergangsbeperkingen nu algemeen beschikbaar voor alle klanten. Met deze nieuwe regel voor het type werkitem kunt u voorkomen dat werkitems van de ene status naar de andere worden verplaatst. U kunt bijvoorbeeld voorkomen dat bugs van Nieuw naar Opgelost gaan. In plaats daarvan moeten ze van Nieuw –> Actief -> Opgelost

In dit voorbeeld worden fouten beperkt van de status Nieuw naar Actief en vervolgens omgezet in plaats van van de status Nieuw naar Opgelost.

U kunt ook een regel maken om statusovergangen per groepslidmaatschap te beperken. Alleen gebruikers in de groep Goedkeurders kunnen bijvoorbeeld gebruikersverhalen verplaatsen van Nieuw -> Goedgekeurd.

Werkitem kopiëren om onderliggende items te kopiëren

Een van de meest aangevraagde functies voor Azure Boards is de mogelijkheid om een werkitem te kopiëren waarmee ook de onderliggende werkitems worden gekopieerd. In deze sprint hebben we een nieuwe optie toegevoegd om onderliggende werkitems toe te voegen aan het dialoogvenster voor het kopiëren van werkitems. Als deze optie is geselecteerd, kopieert u het werkitem en kopieert u alle onderliggende werkitems (maximaal 100).

Op deze pagina ziet u de nieuwe optie in Azure Boards voor het opnemen van onderliggende werkitems in een gekopieerd werkitem.

Verbeterde regels voor geactiveerde en opgeloste velden

Tot nu toe zijn de regels voor Geactiveerd op, Geactiveerde datum, Opgelost door en Opgeloste datum een mysterie geweest. Ze zijn alleen ingesteld voor systeemwerkitemtypen en zijn specifiek voor de statuswaarde 'Actief' en 'Opgelost'. In sprint 172 hebben we de logica gewijzigd, zodat deze regels niet langer voor een specifieke status gelden. In plaats daarvan worden ze geactiveerd door de categorie (statuscategorie) waarin de status zich bevindt. Stel dat u de aangepaste status 'Testbehoeften' hebt in de categorie Opgelost. Wanneer het werkitem verandert van 'Actief' in 'Moet worden getest', worden de regels Opgelost op en Opgeloste datum geactiveerd.

Hierdoor kunnen klanten aangepaste statuswaarden maken en nog steeds de velden Geactiveerd op, Geactiveerd op, Opgelost door en Opgeloste datum genereren, zonder aangepaste regels te hoeven gebruiken.

Systeemwerkitemtypen op achterstanden en borden (beperkte preview)

Sinds het begin van het overnameprocesmodel zijn verschillende typen werkitems uitgesloten van het toevoegen aan borden en achterstanden. Deze typen werkitems zijn onder andere:

Proces Type werkitem
Flexibel Probleem
Scrum Belemmering
CMMI Wijzigingsaanvraag
Probleem
Beoordelen
Risico

Vanaf deze sprint staan we een privévoorbeeld toe voor klanten die deze typen werkitems beschikbaar willen maken op een achterstandsniveau.

Gebruik deze Azure Boards-pagina om eerder uitgesloten werkitemtypen toe te voegen aan borden en achterstanden.

Als u geïnteresseerd bent in een voorbeeld van deze functie, stuur dan een e-mail naar ons met de naam van uw organisatie en kunnen we u toegang geven.

Azure-pipelines

Exclusief beleid voor implementatievergrendeling

Met deze update kunt u ervoor zorgen dat slechts één uitvoering tegelijk in een omgeving wordt geïmplementeerd. Als u de controle Exclusief vergrendelen kiest voor een omgeving, wordt slechts één uitvoering uitgevoerd. Volgende uitvoeringen die in die omgeving willen worden geïmplementeerd, worden onderbroken. Zodra de uitvoering met de exclusieve vergrendeling is voltooid, wordt de nieuwste uitvoering voortgezet. Tussenliggende uitvoeringen worden geannuleerd.

Selecteer op de pagina Controle toevoegen exclusieve vergrendeling om ervoor te zorgen dat slechts één uitvoering tegelijk in een omgeving wordt geïmplementeerd.

Fasenfilters voor pijplijnresourcetriggers

In deze sprint hebben we ondersteuning toegevoegd voor 'fasen' als filter voor pijplijnbronnen in YAML. Met dit filter hoeft u niet te wachten totdat de volledige CI-pijplijn is voltooid om uw CD-pijplijn te activeren. U kunt er nu voor kiezen om uw CD-pijplijn te activeren na voltooiing van een specifieke fase in uw CI-pijplijn.

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

Wanneer de fasen in het triggerfilter zijn voltooid in uw CI-pijplijn, wordt er automatisch een nieuwe uitvoering geactiveerd voor uw CD-pijplijn.

Algemene webhook-triggers voor YAML-pijplijnen

Tegenwoordig hebben we verschillende resources (zoals pijplijnen, containers, build en pakketten) waarmee u artefacten kunt gebruiken en geautomatiseerde triggers kunt inschakelen. Tot nu toe kunt u het implementatieproces echter niet automatiseren op basis van andere externe gebeurtenissen of services. In deze release introduceren we ondersteuning voor webhooktriggers in YAML-pijplijnen om integratie van pijplijnautomatisering met elke externe service mogelijk te maken. U kunt zich abonneren op externe gebeurtenissen via de webhooks (GitHub, GitHub Enterprise, Nexus, Artifactory, enzovoort) en uw pijplijnen activeren.

Hier volgen de stappen voor het configureren van de webhooktriggers:

  1. Stel een webhook in uw externe service in. Bij het maken van uw webhook moet u de volgende informatie opgeven:

    • Aanvraag-URL - "https://dev.azure.com/<ADO Organization>/_apis/public/distributedtask/webhooks/<WebHook Name>?api-version=6.0-preview"
    • Geheim: dit is optioneel. Als u uw JSON-nettolading wilt beveiligen, geeft u de geheime waarde op

  2. Maak een nieuwe serviceverbinding voor binnenkomende webhook. Dit is een nieuw geïntroduceerd serviceverbindingstype waarmee u drie belangrijke gegevens kunt definiëren:

    • Webhooknaam: de naam van de webhook moet overeenkomen met de webhook die is gemaakt in uw externe service.
    • HTTP-header : de naam van de HTTP-header in de aanvraag die de hashwaarde van de nettolading bevat voor aanvraagverificatie. In het geval van GitHub is de aanvraagheader bijvoorbeeld 'X-Hub-Signature'
    • Geheim : het geheim wordt gebruikt om de nettolading-hash te parseren die wordt gebruikt voor de verificatie van de binnenkomende aanvraag (dit is optioneel). Als u een geheim hebt gebruikt bij het maken van uw webhook, moet u dezelfde geheime sleutel opgeven

    Configureer webhooktriggers op de pagina Serviceverbinding bewerken.

  3. Er wordt een nieuw resourcetype aangeroepen webhooks in YAML-pijplijnen. Als u zich wilt abonneren op een webhook-gebeurtenis, moet u een webhookresource in uw pijplijn definiëren en deze naar de binnenkomende webhookserviceverbinding laten verwijzen. U kunt ook aanvullende filters definiëren voor de webhookresource op basis van de JSON-nettoladinggegevens om de triggers voor elke pijplijn verder aan te passen en u kunt de nettoladinggegevens gebruiken in de vorm van variabelen in uw taken.

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. Wanneer een webhookgebeurtenis wordt ontvangen door de inkomende webhookserviceverbinding, wordt een nieuwe uitvoering geactiveerd voor alle pijplijnen die zijn geabonneerd op de webhookgebeurtenis.

Problemen met YAML-resourcetriggers ondersteunen en traceerbaarheid

Het kan verwarrend zijn wanneer pijplijntriggers niet kunnen worden uitgevoerd zoals verwacht. Om dit beter te begrijpen, hebben we een nieuw menu-item toegevoegd op de pagina pijplijndefinitie met de naam 'Triggerproblemen' waar informatie wordt weergegeven met betrekking tot waarom triggers niet worden uitgevoerd.

Resourcetriggers kunnen om twee redenen niet worden uitgevoerd.

  1. Als de bron van de opgegeven serviceverbinding ongeldig is of als er syntaxisfouten in de trigger zijn, wordt de trigger helemaal niet geconfigureerd. Deze worden weergegeven als fouten.

  2. Als de triggervoorwaarden niet overeenkomen, wordt de trigger niet uitgevoerd. Wanneer dit gebeurt, wordt er een waarschuwing weergegeven, zodat u kunt begrijpen waarom de voorwaarden niet overeenkomen.

    Op deze pagina voor pijplijndefinities met de naam Triggerproblemen wordt informatie weergegeven over waarom triggers niet worden uitgevoerd.

We hebben een waarschuwingsbanner toegevoegd aan de pagina pijplijnen om gebruikers te waarschuwen voor lopende incidenten in uw regio, wat mogelijk van invloed is op uw pijplijnen.

Azure Artifacts

Mogelijkheid om binnen het bereik van de organisatiefeeds te maken vanuit de gebruikersinterface

We brengen de mogelijkheid terug voor klanten om binnen het bereik van de organisatie feeds te maken en te beheren via de webgebruikersinterface voor zowel on-premises als gehoste services.

U kunt nu in de gebruikersinterface org-scoped feeds maken door naar Artifacts -> Feed maken en een type feed te kiezen binnen Het bereik.

Maak binnen het bereik van de organisatie feeds door Artefacten te selecteren, vervolgens Feed maken en een type feed binnen Het bereik te selecteren.

Hoewel we het gebruik van feeds met projectbereik wel aanbevelen in overeenstemming met de rest van Azure DevOps-aanbiedingen, kunt u opnieuw feeds met organisatiebereik maken, beheren en gebruiken via de gebruikersinterface en verschillende REST API's. Raadpleeg onze feedsdocumentatie voor meer informatie.

Volgende stappen

Notitie

Deze functies worden de komende twee tot drie weken uitgerold.

Ga naar Azure DevOps en kijk eens.

Ga naar Azure DevOps

Feedback geven

We horen graag wat u van deze functies vindt. Gebruik het Help-menu om een probleem te melden of een suggestie op te geven.

Een suggestie doen

U kunt ook advies krijgen en uw vragen beantwoorden door de community op Stack Overflow.

Met vriendelijke groet,

Aaron Hallberg