Sdílet prostřednictvím


Omezení přechodů stavu pracovních položek

Po několikasprintch

Další informace najdete v seznamu funkcí níže.

Funkce

Azure Boards

Azure Pipelines

Azure Artifacts

Azure Boards

Pravidla omezení přechodu stavu

Po několikasprintch Toto nové pravidlo typu pracovní položky umožňuje omezit přesun pracovních položek z jednoho stavu do jiného. Můžete například omezit, aby chyby přecháděly z nabídky Nové na Vyřešeno. Místo toho musí přejít z nového –> aktivní –> vyřešeno

Tento příklad omezuje chyby tak, aby přešly z nového stavu na aktivní a pak se přeložily ze stavu Nový na Vyřešeno.

Můžete také vytvořit pravidlo, které omezí přechody stavu podle členství ve skupině. Například pouze uživatelé ve skupině Schvalovatelé můžou přesouvat uživatelské scénáře z nového –> schváleného.

Kopírování pracovní položky pro kopírování podřízených položek

Jednou z nejžádaných funkcí pro Azure Boards je možnost kopírovat pracovní položku, která také kopíruje podřízené pracovní položky. V tomto sprintu jsme do dialogového okna kopírovat pracovní položku přidali novou možnost Zahrnout podřízené pracovní položky. Pokud je tato možnost vybraná, zkopíruje pracovní položku a zkopíruje všechny podřízené pracovní položky (až 100).

Tato stránka zobrazuje novou možnost v Azure Boards, která do zkopírované pracovní položky zahrne podřízené pracovní položky.

Vylepšená pravidla pro aktivovaná a vyřešená pole

Až doteď jsou pravidla pro aktivované uživatelem, aktivovaným datem, vyřešeným datem a vyřešeným datem záhadou. Jsou nastaveny pouze pro typy systémových pracovních položek a jsou specifické pro hodnotu stavu "Aktivní" a "Vyřešeno". Ve sprintu 172 jsme změnili logiku tak, aby tato pravidla již nebyla určena pro konkrétní stav. Místo toho se aktivují podle kategorie (kategorie stavu), ve které se stav nachází. Řekněme například, že máte vlastní stav "Potřebuje testování" v kategorii Vyřešeno. Když se pracovní položka změní z "Aktivní" na "Potřebuje testování", aktivují se pravidla Vyřešeno podle a Vyřešené datum .

Zákazníci tak můžou vytvářet vlastní hodnoty stavu a stále generovat pole Aktivované podle, Datum aktivace, Vyřešeno a Vyřešené datum , aniž by museli používat vlastní pravidla.

Typy systémových pracovních položek v backlogech a panelech (privátní verze Preview)

Od vzniku modelu procesu dědičnosti bylo z přidávání do panelů a backlogů vyloučeno několik typů pracovních položek. Mezi tyto typy pracovních položek patří:

Zpracovat Typ pracovní položky
Agilita Problém
Scrum Překážka
CMMI Žádost o změnu
Problém
Přehled
Riziko

Od tohoto sprintu povolujeme uživatelům, kteří chtějí povolit dostupnost těchto typů pracovních položek na jakékoli úrovni backlogu, privátní verzi Preview.

Na této stránce Azure Boards můžete do panelů a backlogů přidat dříve vyloučené typy pracovních položek.

Pokud vás zajímá náhled této funkce, pošlete nám prosím e-mail s názvem vaší organizace a my vám můžeme poskytnout přístup.

Azure Pipelines

Zásady výhradního uzamčení nasazení

Díky této aktualizaci můžete zajistit, aby se do prostředí současně nasadí jenom jedno spuštění. Výběrem kontroly "Exkluzivní zámek" v prostředí bude pokračovat pouze jedno spuštění. Další spuštění, která chcete nasadit do daného prostředí, se pozastaví. Po dokončení spuštění s výhradním zámkem bude pokračovat nejnovější spuštění. Všechna zprostředkující spuštění budou zrušena.

Na stránce Přidat zaškrtnutí vyberte Výhradní zámek, abyste zajistili, že se do prostředí současně nasadí jenom jedno spuštění.

Filtry fází pro triggery prostředků kanálu

V tomto sprintu jsme přidali podporu dílčích fází jako filtr pro prostředky kanálu v YAML. S tímto filtrem nemusíte čekat, až se dokončí celý kanál CI, aby se aktivoval kanál CD. Teď se můžete rozhodnout, že kanál CD aktivujete po dokončení konkrétní fáze v kanálu 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

Po úspěšném dokončení fází uvedených ve filtru triggerů v kanálu CI se pro váš kanál CD automaticky aktivuje nové spuštění.

Obecné triggery založené na webhoocích pro kanály YAML

Dnes máme různé prostředky (například kanály, kontejnery, sestavení a balíčky), prostřednictvím kterých můžete využívat artefakty a povolit automatizované triggery. Dosud však nebylo možné automatizovat proces nasazení na základě jiných externích událostí nebo služeb. V této verzi představujeme podporu triggeru webhooku v kanálech YAML, která umožňuje integraci automatizace kanálů s jakoukoli externí službou. Můžete se přihlásit k odběru jakýchkoli externích událostí prostřednictvím svých webhooků (GitHub, GitHub Enterprise, Nexus, Artifactory atd.) a aktivovat vaše kanály.

Tady je postup konfigurace triggerů webhooku:

  1. Nastavte webhook na externí službu. Při vytváření webhooku musíte zadat následující informace:

    • Adresa URL žádosti – Organizacehttps://dev.azure.com/<> ADO/ _apis/public/distributedtask/webhooks/<Název> webhooku?api-version=6.0-preview
    • Tajný kód – Toto je volitelné. Pokud potřebujete datovou část JSON zabezpečit, zadejte hodnotu Tajné .
  2. Vytvořte nové připojení služby Příchozí webhook. Jedná se o nově zavedený typ připojení služby, který vám umožní definovat tři důležité informace:

    • Název webhooku: Název webhooku by měl odpovídat webhooku vytvořenému ve vaší externí službě.
    • Hlavička HTTP – název hlavičky HTTP v požadavku, který obsahuje hodnotu hash datové části pro ověření požadavku. Například v případě GitHubu bude hlavička požadavku X-Hub-Signature.
    • Tajný kód – Tajný kód se používá k analýze hodnoty hash datové části použité k ověření příchozího požadavku (to je volitelné). Pokud jste při vytváření webhooku použili tajný kód, budete muset zadat stejný tajný klíč.

    Na stránce Upravit připojení služby nakonfigurujte triggery webhooku.

  3. V kanálech YAML se zavádí nový typ webhooks prostředku. Pokud se chcete přihlásit k odběru události webhooku, musíte v kanálu definovat prostředek webhooku a nasměrovat ho na připojení služby Příchozí webhook. Můžete také definovat další filtry pro prostředek webhooku na základě dat datové části JSON a dále přizpůsobit triggery pro každý kanál a data datové části můžete využívat ve formě proměnných ve vašich úlohách.

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. Pokaždé, když připojení služby Příchozí webhook obdrží událost webhooku, aktivuje se nové spuštění pro všechny kanály, které se přihlásí k odběru události webhooku.

Problémy s triggerem prostředků YAML – podpora a sledovatelnost

Může to být matoucí, když se triggery kanálu nespustí podle očekávání. Abychom to lépe pochopili, přidali jsme novou položku nabídky na stránce definice kanálu s názvem Problémy s triggery, kde se zobrazí informace týkající se toho, proč se triggery nespouštějí.

Triggery prostředků se nedají spustit ze dvou důvodů.

  1. Pokud je zdroj zadaného připojení služby neplatný nebo pokud trigger obsahuje nějaké chyby syntaxe, trigger se vůbec nenakonfiguruje. Zobrazují se jako chyby.

  2. Pokud se podmínky triggeru neshodují, trigger se nespustí. Kdykoli k tomu dojde, zobrazí se upozornění, abyste pochopili, proč se podmínky neshodovaly.

    Tato stránka definice kanálu s názvem Problémy s triggery zobrazuje informace o tom, proč triggery nejsou spuštěné.

Na stránku kanálů jsme přidali upozornění, které uživatelům upozorňují na probíhající incidenty ve vaší oblasti, což může mít vliv na vaše kanály.

Azure Artifacts

Možnost vytvářet informační kanály v oboru organizace z uživatelského rozhraní

Zákazníkům vracíme možnost vytvářet a spravovat informační kanály omezené organizací prostřednictvím webového uživatelského rozhraní pro místní i hostované služby.

Kanály s oborem organizace teď můžete vytvářet prostřednictvím uživatelského rozhraní tak, že přejdete na Artefakty –> Vytvořit informační kanál a zvolíte typ informačního kanálu v rámci oboru.

Kanály v oboru organizace můžete vytvořit tak, že vyberete Artefakty, pak Vytvoříte informační kanál a vyberete typ informačního kanálu v rámci oboru.

I když doporučujeme používat informační kanály omezené na projekty v souladu se zbývajícími nabídkami Azure DevOps, můžete znovu vytvářet, spravovat a používat informační kanály v oboru organizace prostřednictvím uživatelského rozhraní a různých rozhraní REST API. Další informace najdete v dokumentaci k informačním kanálům.

Další kroky

Poznámka:

Tyto funkce se budou zavádět během následujících dvou až tří týdnů.

Přejděte na Azure DevOps a podívejte se na ně.

Jak poskytnout zpětnou vazbu

Rádi bychom slyšeli, co si o těchto funkcích myslíte. Pomocí nabídky nápovědy můžete nahlásit problém nebo poskytnout návrh.

Vytvoření návrhu

Můžete také získat rady a své otázky zodpovězené komunitou ve službě Stack Overflow.

Díky,

Aaron Hallberg