Přizpůsobte a rozšiřte pracovní postupy pro žádosti o přijetí změn pomocí stavu žádosti

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

žádosti o přijetí změn představují skvělý nástroj pro usnadnění kontrol kódu a správu přesunu kódu v úložišti. Pravidla pro větve zajišťují kvalitu kódu během procesu pull requestu tím, že stanovují požadavky, které musí být splněny 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 pull requestů. Stavy žádostí o přijetí změn se integrují do pracovního postupu a umožňují externím službám programově schválit změnu kódu přidružením jednoduchých informací o úspěchu nebo selhání k této žádosti. Volitelně je možné žádosti o přijetí změn blokovat, dokud externí služba změnu neschválí.

Požadavky

Kategorie	Požadavky
Přístup k projektu	Člen projektu.
Oprávnění	- Zobrazit kód v soukromých projektech: Alespoň Základní přístup. - Klonování nebo přispívání do kódu v soukromých projektech: Člen skupiny zabezpečení Contributors nebo osoba s odpovídajícími oprávněními v projektu. – Nastavte oprávnění pro větev nebo úložiště: Správa oprávnění oprávnění pro větev nebo úložiště. – Změnit výchozí větev: Upravit zásady oprávnění pro úložiště. – Import úložiště: Člen skupiny zabezpečení Projektoví administrátoři nebo oprávnění Vytvořit úložiště na úrovni projektu Git nastavená na Povolit. Další informace najdete v tématu Nastavení oprávnění úložiště Git.
Služby	Repozitáře povoleny.
Nástroje	Volitelný. Použijte příkazy az repos: Azure DevOps CLI.

Poznámka:

Ve veřejných projektech mají uživatelé s přístupem Stakeholder plný přístup do Azure Repos, kde mohou zobrazovat, klonovat a přispívat ke kódu.

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 možnost přiřadit informace o úspěchu nebo selhání k žádosti o přijetí změn.
• Politika stavu – poskytuje mechanismus pro blokování dokončování požadavků na začlenění, dokud stav požadavku na začlenění neoznačí úspěch.
• Vlastní akce – poskytují způsob, jak pomocí rozšíření pro Azure DevOps Services rozšířit nabídku stavu.

V tomto tématu se dozvíte o stavech pull requestů a o jejich využití v pracovním postupu PR.

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, notApplicablenebo error.
• Popis. Řetězec, který popisuje stav koncovému uživateli.
• Kontext. Název stavu – obvykle popisující entitu, která zveřejňuje stav.
• 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. Zvažte služby CI, která je nutná k sestavení všech změn kódu v projektu. Když tato služba vyhodnotí změny v pull requestu, musí zpětně publikovat výsledky sestavení a testů. U změn, které prošly sestavením, se může ve žádosti o sloučení (PR) 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 by byl zobrazen koncovému uživateli v zobrazení PR Podrobnosti:

• state se uživateli zobrazí pomocí ikony (zelená fajfka pro succeeded, červený křížek pro failed, hodiny pro pendinga červený vykřičník pro error).
• Vedle ikony se zobrazí description a context je k dispozici v popisu.
• Při použití targetUrl se popis zobrazí jako odkaz na adresu URL.

Aktualizace stavu

Služba může aktualizovat stav pro jeden PR tak, že zveřejní další stavy, přičemž se pro každou jedinečnou contextzobrazí pouze ten nejnovější. Zveřejňování více statusů pomáhá uživatelům spravovat očekávání. Například publikování stavu pending je dobrým způsobem, jak uživateli potvrdit, že systém obdržel událost a začíná pracovat. Použití informativních description, jako jsou například následující příklady, může uživateli pomoct dále pochopit, jak systém funguje:

• "Sestavení zařazeno do fronty"
• Stavba probíhá
• Sestavení bylo úspěšné.

Stav iterace

Když se zdrojová větev v PR 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 zveřejnit nový stav pro každou iteraci pull requestu. Zveřejnění stavu u konkrétní iterace pull requestu zaručuje, že se tento stav vztahuje pouze na kód, který byl vyhodnocen, a ne na žádné budoucí aktualizace.

Poznámka:

Pokud vytvářená žádost o přijetí změn obsahuje více než 100 000 upravených souborů, pak z důvodů výkonu a stability tato žádost o přijetí změn nebude podporovat iterace. To znamená, že jakákoli další změna v tomto PR bude zahrnuta, ale pro tuto změnu nebude vytvořena žádná nová iterace. Kromě toho všechny pokusy o vytvoření stavu pro neexistující iteraci vrátí chybu.

Naopak, pokud se uvedený stav vztahuje na celý pull request nezávisle na kódu, může být zveřejnění v iteraci zbytečné. Například kontrola, jestli autor (neměnná vlastnost pull requestu) patří do konkrétní skupiny, by měla být vyhodnocena pouze jednou, a stav opakování nebude potřeba.

Když konfigurujete zásady stavu, pokud se používá stav iterace, Podmínky obnovení by měly být nastaveny na Stav resetování vždy, když dojde k novým změnám. To dále zaručuje, že PR nebude možné sloučit, dokud nejnovější iterace nebude mít stav succeeded.

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

Politika stavu

Využitím statusu lze uživatelům v rámci práce s Pull Requesty zpřístupnit detaily z externí služby. Někdy stačí sdílení informací o PR, ale v jiných případech by PR měly být zablokovány před sloučením, dokud nebudou splněny požadavky. Stejně jako u předem nastavených zásad zásady stavu poskytují způsob, jak externím službám zablokovat dokončení žádosti o přijetí změn, dokud nebudou splněny požadavky. Pokud je zásada požadovaná, musí být splněna, aby mohla být žádost o přijetí změn dokončena. 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 jsou konfigurovány stejně jako jiné zásady větví. Při přidávání nové statusové politiky je nutné zadat název a žánr statusové politiky. 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 ve formátu genre/name.

Když je specifikována zásada stavu, vyžaduje, aby byl přítomen stav succeeded s context odpovídající vybranému názvu, a tím byla zásada splněna.

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, jakmile se vytvoří žádost 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ásady se po vytvoření žádosti o přijetí změn použijí. Pomocí této možnosti nebude pravidlo po vytvoření pull requestu schváleno, dokud se nezaúčtuje stav succeeded. Žádost o přijetí (PR) může být označena jako osvobozená od zásady zveřejněním stavu notApplicable, což odstraní požadavek na dodržení zásady.

2. Podmínky – Pravidla se neuplatní, dokud není do žádosti o přijetí změn uveden první status.

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 aktualizovat, aby byly tyto zásady povinné. Tyto zásady orchestrace mohou být označeny succeeded, když je vyhodnocení dokončeno, nebo mohou být označeny notApplicable, aby naznačily v rámci PR, že se zásada nevztahuje.

Vlastní akce

Kromě předdefinovaných událostí služby, které mohou aktivovat službu pro aktualizaci stavu žádosti o přijetí změn, je možné rozšířit nabídku stavu pomocí rozšíření Azure DevOps Services, aby koncoví uživatelé mohli spouštět aktivační akce. Pokud například stav odpovídá testovacímu spuštění, které může koncový uživatel restartovat, může existovat položka nabídky Restart ve stavové nabídce, která by spustila testy. Pokud chcete přidat stavovou nabídku, budete muset použít kontribuční model . Další informace najdete v ukázce rozšíření Azure DevOps.

Další kroky

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

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