Přizpůsobení a rozšíření pracovních postupů žádostí o přijetí změn se stavem žádosti o přijetí změn

Azure DevOps Services | Azure DevOps Server 2022 – Azure DevOps Server 2019

Žádosti o přijetí změn jsou skvělým nástrojem pro usnadnění kontrol kódu a správu přesunu kódu v rámci úložiště. Zásady větve vynucují kvalitu kódu během procesu žádosti o přijetí změn tím, že stanoví požadavky, které je potřeba provést pro každou změnu kódu. Tyto zásady umožňují týmům vynucovat mnoho osvědčených postupů souvisejících s kontrolou kódu a spouštěním automatizovaných sestavení, ale mnoho týmů má další požadavky a ověření, které se mají provádět s kódem. Pro pokrytí těchto individuálních a vlastních potřeb nabízí Azure Repos stavy žádostí o přijetí změn. Stavy žádostí o přijetí změn se integrují do pracovního postupu žádosti o přijetí změn a umožňují externím službám programově odhlásit změnu kódu přidružením jednoduchých informací o typu úspěchu nebo selhání k žádosti o přijetí změn. Volitelně je možné žádosti o přijetí změn blokovat, dokud externí služba změnu neschválí.

Integrace do pracovního postupu žádosti o přijetí změn zahrnuje několik různých konceptů:

• Stav žádosti o přijetí změn – poskytuje službám způsob, jak přidružit informace o úspěchu nebo selhání k žádosti o přijetí změn.
• Zásady stavu – poskytuje mechanismus blokování dokončování žádostí o přijetí změn, dokud stav žádosti o přijetí změn nezoznačí úspěch.
• Vlastní akce – poskytuje způsob, jak rozšířit nabídku stavu pomocí rozšíření Azure DevOps Services.

V tomto tématu se dozvíte o stavech žádostí o přijetí změn a o tom, jak je můžete použít k integraci v pracovním postupu žádosti o přijetí změn.

Stav žádosti o přijetí změn

Stav žádosti o přijetí změn poskytuje službám způsob přidružení jednoduchých informací o typu úspěchu nebo selhání k žádosti o přijetí změn pomocí rozhraní API stavu. Stav se skládá ze čtyř klíčových částí dat:

• Stav. Jeden z následujících předdefinovaných stavů: succeeded, failed, pending, notSet, notApplicable, nebo error.
• Popis. Řetězec, který popisuje stav koncovému uživateli.
• Kontext. Název stavu – obvykle popisující entitu, která zveřejňuje stav.
• Adresa URL. Odkaz, na kterém můžou uživatelé získat další informace specifické pro stav.

Stav je v podstatě způsob, jakým uživatel nebo služba publikuje hodnocení žádosti o přijetí změn a poskytuje odpověď na otázky, jako jsou:

• Splňovaly změny požadavky?
• Kde se dozvím další informace o tom, co potřebuji udělat, aby bylo možné splnit požadavky?

Podívejme se na příklad. Vezměte v úvahu službu CI, která je nutná k sestavení všech změn kódu v projektu. Když tato služba vyhodnotí změny v žádosti o přijetí změn, musí publikovat výsledky sestavení a testů. U změn, které předávají sestavení, se může v žádosti o přijetí změn publikovat stav podobný tomuto:

{
    "state": "succeeded",
    "description": "CI build succeeded",
    "context": {
        "name": "my-ci-system",
        "genre": "continuous-integration"
    },
    "targetUrl": "http://contoso.com/CI/builds/1"
}

Tento stav se zobrazí koncovému uživateli v zobrazení podrobností žádosti o přijetí změn:

• Zobrazí state se uživateli pomocí ikony (zelená kontrola succeeded, červené X pro failed, hodiny pro pendinga červené ! pro error).
• Zobrazí description se vedle ikony a context je k dispozici v popisu.
• targetUrl Po použití se popis vykreslí jako odkaz na adresu URL.

Aktualizace stavu

Služba může aktualizovat stav žádosti o přijetí změn pro jednu žádost o přijetí změn publikováním dalších stavů, pouze nejnovější z nich se zobrazí pro každý jedinečný context. Publikování více stavů pomáhá uživatelům spravovat očekávání. Publikování stavu je například dobrým způsobem, pending jak uživatele potvrdit, že systém obdržel událost a že začíná pracovat. Použití informativních informací description , jako jsou například následující příklady, může uživateli dále pomoct pochopit, jak systém funguje:

• "Sestavení zařazeno do fronty"
• Probíhající sestavení
• Sestavení bylo úspěšné.

Stav iterace

Když se zdrojová větev v žádosti o přijetí změn změní, vytvoří se nová iterace pro sledování nejnovějších změn. Služby, které vyhodnocují změny kódu, budou chtít publikovat nový stav pro každou iteraci žádosti o přijetí změn. Účtování stavu do konkrétní iterace žádosti o přijetí změn zaručuje, že se tento stav vztahuje pouze na kód, který byl vyhodnocen a žádná z budoucích aktualizací.

Pokud se stav publikovaný naopak vztahuje na celou žádost o přijetí změn nezávisle na kódu, může být účtování do iterace zbytečné. Například kontrola, jestli autor (neměnná vlastnost ŽÁDOSTI o přijetí změn) patří do konkrétní skupiny, bude třeba vyhodnotit pouze jednou a stav iterace nebude potřeba.

Když konfigurujete zásady stavu, pokud se používá stav iterace, měly by být podmínky resetování nastaveny na Stav resetování, kdykoli dojde k novým změnám. To dále zaručuje, že žádost o přijetí změn nebude moci být sloučena, dokud nejnovější iterace nebude mít stav succeeded.

Podívejte se na příklady rozhraní REST API pro publikování stavu iterace a žádosti o přijetí změn.

Zásady stavu

Pomocí samotného stavu je možné uživatelům v rámci žádosti o přijetí změn poskytnout podrobnosti z externí služby. Sdílení informací o žádosti o přijetí změn je někdy vše, co je potřeba, ale v jiných případech by žádosti o přijetí změn měly být zablokovány sloučením, dokud nebudou splněny požadavky. Podobně jako u předem nastavených zásad poskytují zásady stavu způsob, jak externím službám blokovat dokončování žádostí o přijetí změn, dokud nebudou splněny požadavky. Pokud je zásada požadovaná, musí předat, aby mohla žádost o přijetí změn dokončit. Pokud je zásada nepovinná, je pouze informativní a k dokončení žádosti o přijetí změn se nevyžaduje stav succeeded .

Zásady stavu se konfigurují stejně jako jiné zásady větve. Při přidávání nové zásady stavu musí být zadán název a žánr zásady stavu. Pokud byl stav dříve publikován, můžete ho vybrat ze seznamu; Pokud se jedná o novou zásadu, můžete zadat název zásady v názvu žánru/formátu.

Pokud je zadaná zásada stavu, vyžaduje, aby se pro předání této zásady zobrazoval stav succeeded s context odpovídajícím vybraným názvem.

Můžete také vybrat autorizovaný účet , který vyžaduje, aby konkrétní účet mohl publikovat stav, který bude zásadu schvalovat.

Použitelnost zásad

Možnosti použitelnosti zásad určují, jestli se tato zásada použije hned po vytvoření žádosti o přijetí změn, nebo jestli se zásada použije až po odeslání prvního stavu do žádosti o přijetí změn.

1. Použít ve výchozím nastavení – Zásada se použije hned po vytvoření žádosti o přijetí změn. S touto možností zásady neprojdou po vytvoření žádosti o přijetí změn, dokud succeeded se nezobrazí stav. Žádost o přijetí změn může být označena vyloučenou ze zásady zveřejněním stavu notApplicable, který odebere požadavek na zásadu.

2. Podmíněné – Zásada se nevztahuje, dokud se do žádosti o přijetí změn nezaúčtuje první stav.

Tyto možnosti lze společně použít k vytvoření sady dynamických zásad. Zásady orchestrace nejvyšší úrovně je možné nastavit tak, aby se ve výchozím nastavení použily, když se žádost o přijetí změn vyhodnocuje pro příslušné zásady. Jakmile se pak určí další podmíněné zásady, které se použijí (třeba na základě konkrétního výstupu sestavení), může se stav publikovat, aby se vyžadovaly. Tuto zásadu orchestrace je možné označit succeeded , když se dokončí vyhodnocení, nebo může být označená notApplicable tak, aby indikoval žádosti o přijetí změn, že se zásada nevztahuje.

Vlastní akce

Kromě předdefinovaných událostí háku služby, které můžou aktivovat službu za účelem aktualizace stavu žádosti o přijetí změn, je možné rozšířit nabídku stavu pomocí rozšíření Azure DevOps Services, aby koncovému uživateli poskytla akce triggeru. Pokud například stav odpovídá testovacímu spuštění, které může koncový uživatel restartovat, může mít položku nabídky Restartovat do stavové nabídky, která by aktivovala spuštění testů. Pokud chcete přidat stavovou nabídku, budete muset použít model příspěvku. Další informace najdete v ukázce rozšíření Azure DevOps.

Další kroky

Přečtěte si další informace o rozhraní API pro stav žádosti o přijetí změn a podívejte se na návody:

• Vytvoření serveru stavu žádosti o přijetí změn pomocí Node.js
• Vytvoření vlastních zásad větvení pomocí Azure Functions
• Konfigurace zásad větvení pro externí službu