Nastavení a správa zásad větví

služby Azure DevOps | Azure DevOps Server | Azure DevOps Server 2022

Pomocí zásad větví můžete chránit důležité větve tím, že před sloučením změn vyžadují nabídky změn, recenzenty, sestavení a další kontroly. Tento článek ukazuje, jak nakonfigurovat a spravovat zásady větví na webovém portálu Azure DevOps a v rozhraní příkazového řádku Azure DevOps. Souhrn dostupných zásad větví a pokynů k větvení najdete v tématu o větvích a zásadách větví.

Komplexní průvodce zabezpečením zahrnující zásady větví, řízení přístupu k úložišti, podepisování potvrzení a scénáře implementace v reálném světě najdete v tématu Zabezpečené úložiště a žádosti o přijetí změn.

Nemůžete odstranit větev, u které jsou nakonfigurované povinné zásady, a všechny změny musí projít přes žádosti o přijetí změn (PR).

Návod

Později v tomto článku můžete k provedení tohoto úkolu použít AI nebo si pro začátek přečíst Povolení asistence AI pomocí serveru Azure DevOps MCP.

Požadavky

Requirement Podrobnosti
Permissions Být členem skupiny zabezpečení Project Administrators nebo mít oprávnění k úpravám na úrovni úložiště. Další informace najdete v tématu Nastavení oprávnění úložiště Git.
nastavení rozhraní příkazového řádku Azure DevOps (volitelné) Pokud chcete používat příkazy Azure DevOps CLI az repos policy, projděte si článek Začínáme s Azure DevOps CLI.
Zacílení na repozitář pro CLI (volitelné) Před vytvořením nebo aktualizací zásad v rozhraní příkazového řádku identifikujte ID úložiště spuštěním az repos listpříkazu . Chcete-li se vyhnout opakování --org a --project, nastavte výchozí hodnoty pomocí az devops configure --defaults.
Závislosti zásad Než nakonfigurujete Ověření sestavení, mějte připravený sestavovací kanál. Než nakonfigurujete kontroly stavu, ujistěte se, že externí služba nebo integrovaná služba už dokáže odesílat stav pull requestu.
Nastavení pomoci s AI (volitelné) Pokud chcete s Azure DevOps serverem MCP používat pomoc s AI, použijte Azure DevOps Services, povolte režim agenta v pomocníkovi a nainstalujte Node.js 20.0 nebo novější. Další informace najdete v tématu Povolení pomoci s AI s Azure DevOps MCP Server.
Requirement Podrobnosti
Permissions Být členem skupiny zabezpečení Project Administrators nebo mít oprávnění k úpravám na úrovni úložiště. Další informace najdete v tématu Nastavení oprávnění úložiště Git.

Otevřít nastavení zásad větve

Otevřete nastavení zásad pro větev ve webovém portálu:

  1. Vyberte úložiště>a větve.
  2. Najděte větev, kterou chcete spravovat.
  3. Vyberte ikonu Další možnosti vedle větve a pak vyberte Zásady větve.

Snímek obrazovky, který ukazuje položku v nabídce Větve.

Můžete také otevřít nastavení zásad větví v Nastavení projektu>Úložiště>Zásady>Zásady větví><Název větve>.

Větve, které mají zásady, zobrazují ikonu zásad. Výběrem ikony přejdete přímo do nastavení zásad větve.

Seznam můžete procházet nebo hledat větev v poli Prohledat název větve .

Snímek obrazovky znázorňující otevření zásad větve z místní nabídky

Nakonfigurujte zásady na stránce nastavení větve. Pomocí následujících částí zapněte nebo aktualizujte existující zásady.

Nastavte minimální zásady pro recenzenty

Před dokončením pull requestu vyžadovat schválení od minimálního počtu kontrolujících.

Chcete-li nastavit zásadu, v části Zásady větve nastavte Požadovat minimální počet kontrolorů na Zapnuto. Zadejte požadovaný počet revidujících a vyberte některou z následujících možností:

Snímek obrazovky znázorňující zásadu Povolit revize kódu

  • Vyberte povolit žadatelům schválit vlastní změny, aby autor žádosti o přijetí mohl hlasovat o schválení. V opačném případě může tvůrce PR stále hlasovat Schválit, ale jeho hlas se nezapočítává do minimálního počtu recenzentů.

  • Pokud chcete vynutit oddělení povinností, vyberte Zakázat nejnovějšímu schvalujícímu schválit vlastní změny. Ve výchozím nastavení může každý, kdo má ve zdrojové větvi oprávnění push, přidávat commity i hlasovat o schválení pull requestu. Když vyberete tuto možnost, znamená to, že hlas posledního uživatele, který provádí změny, se nepočítá, i když obvykle může schvalovat své vlastní změny.

  • Vyberte Povolit dokončení, i když někteří recenzenti hlasují pro čekání nebo odmítnutí , aby bylo umožněno dokončení žádosti o přijetí změn, i když někteří recenzenti hlasují proti schválení. Minimální počet revidujících musí stále schvalovat.

  • V části Po zavedení nových změn:
    • Vyberte Vyžadovat alespoň jedno schválení u každé iterace, abyste u poslední změny zdrojové větve vyžadovali alespoň jeden schvalovací hlas. Schválení uživatele se nezapočítává do žádné předchozí neschválené iterace odeslané tímto uživatelem. V důsledku toho se vyžaduje další schválení poslední iterace jiným uživatelem. V Azure DevOps Serveru 2022.1 a novějším je vyžadováno alespoň jedno schválení každé iterace .
    • Vyberte Vyžadovat alespoň jedno schválení v poslední iteraci k tomu, abyste vyžadovali alespoň jeden schvalovací hlas pro poslední změnu zdrojové větve.
    • Pokud chcete odebrat všechna hlasování o schválení, vyberte Obnovit všechna hlasování schválení (nevynuluje hlasy, které chcete odmítnout nebo počkat), ale hlasy můžete odmítnout nebo počkat, kdykoli se změní zdrojová větev.
    • Výběrem možnosti Resetovat všechny hlasy recenzentů kódu odeberete všechny hlasy recenzentů kdykoli dojde ke změně zdrojové větve, včetně hlasů ke schválení, odmítnutí nebo čekání.

Pokud všechny ostatní zásady projdou, tvůrce může žádost o přijetí změn dokončit, když ji schválí požadovaný počet revidujících.

Vyžadování propojených pracovních položek

Pro sledování správy úkolů můžete vyžadovat přidružení mezi PR a pracovními položkami. Propojení pracovních položek poskytuje více kontextu pro změny a zajišťuje, že aktualizace procházejí procesem sledování pracovních položek.

Pokud chcete zásadu nastavit, v části Zásady větve nastavte Možnost Vyhledat propojené pracovní položky na Zapnuto. Toto nastavení vyžaduje, aby pracovní položky byly propojeny s žádostí o přijetí změn, aby se žádost o přijetí změn sloučila. Nastavení Volitelné, aby se zobrazovala upozornění, když nejsou propojené pracovní položky, ale povolte dokončení žádosti o přijetí změn.

Snímek obrazovky s vyžadováním propojených pracovních položek v žádostech o změny.

Vyžadovat vyřešení komentářů

Zásady kontroly vyřešení komentářů kontrolují, jestli jsou vyřešené všechny komentáře k PR.

Nastavte Kontrola vyřešení komentářů na Zapnuto, abyste pro vaši větev nastavili zásady řešení komentářů. Pak vyberte, jestli se má zásada nastavit jako povinná nebo nepovinná.

Snímek obrazovky s možností Kontrola rozlišení komentáře

Další informace o práci s komentáři k žádostem o přijetí změn najdete v tématu Kontrola žádostí o přijetí změn.

Omezení typů sloučení

Azure Repos podporuje několik strategií sloučení a ve výchozím nastavení umožňuje všechny. Chcete-li zachovat konzistentní historii větví, vynuťte při dokončení PR strategii sloučení.

Pokud chcete omezit, které typy slučování jsou ve vašem úložišti povolené, nastavte možnost Omezit typy sloučení na Hodnotu Zapnuto .

Snímek obrazovky omezení typů sloučení

  • Základní sloučení (bez rychlého posunu vpřed) vytvoří slučovací commit v cílové větvi, jehož rodičovské větve jsou cílová a zdrojová větev.
  • Squash merge vytvoří lineární historii s jediným potvrzením v cílové větvi, která zahrnuje změny ze zdrojové větve. Přečtěte si další informace o sloučení squashů a o tom, jak ovlivňuje historii větví.
  • Rebase a fast-forward vytvoří lineární historii přehráním zdrojových potvrzení do cílové větve bez potvrzení sloučení.
  • Rebase with merge commit spustí původní commity na cílovou větev a také vytvoří merge commit.

Nastavit ověřování sestavení

Nastavte zásadu, která vyžaduje, aby změny v PR byly úspěšně sestaveny, než bude možné PR dokončit. Zásady sestavování snižují přestávky a zajistí, že výsledky testů jsou úspěšné. Zásady vytváření pomáhají i v případě, že ve svých vývojových větvích používáte kontinuální integraci (CI), abyste mohli včas zachytit problémy.

Když nastavíte aktivační mechanismus zásady na Automaticky, zásada ověření sestavení zařadí nové sestavení do fronty, když vytvoříte nové PR nebo odešlete změny do existujícího PR, který cílí na danou větev. Pokud nastavíte trigger zásad na ruční, musí uživatelé zařazují sestavení do fronty sami. V obou případech zásada vyhodnocuje výsledky sestavení a určí, jestli je možné žádost o přijetí změn dokončit.

Důležité

Před zadáním zásady ověření sestavení vytvořte kanál buildu. Pokud nemáte potrubí, podívejte se na Vytvoření potrubí buildu. Zvolte typ sestavení, který odpovídá vašemu typu projektu.

Přidejte zásadu ověřování sestavení

  1. Vyberte tlačítko + vedle ověření sestavení.

    Snímek obrazovky znázorňující tlačítko Přidat vedle ověření sestavení

  2. Vyplňte formulář Nastavit zásady sestavení:

    Snímek obrazovky s nastavením zásad buildu

    • Vyberte kanál buildu.

  • Volitelně můžete nastavit filtr cesty. Přečtěte si další informace o filtrech cest v zásadách větvových politik.

  • V části Aktivační událost vyberte Automaticky (při každé aktualizaci zdrojové větve) nebo Ruční.

  • V části Požadavek na politiku vyberte Povinné nebo Volitelné. Pokud zvolíte Povinné, sestavení musí být úspěšně dokončeno, aby se dokončily pull requesty. Zvolte Volitelné, pokud chcete poskytnout oznámení o selhání sestavení, a přesto umožnit dokončení pull requestů.

  • Nastavte vypršení platnosti sestavení, abyste měli jistotu, že aktualizace chráněné větve nepřeruší vývoj pro otevřené pull requesty.

    • Ihned při aktualizaci názvu větve: Tato možnost nastaví stav zásad sestavení žádosti o přijetí změn na selhání při každé aktualizaci větve a znovu zařadí sestavení do fronty. Toto nastavení zajistí, že se změny v pull requestu úspěšně sestaví i v případě, že se změní chráněná větev.

      Tato možnost je nejvhodnější pro týmy, jejichž důležité větve mají několik změn. Týmy pracující na zaneprázdněných vývojových větvích mohou považovat čekání na sestavení při každé aktualizaci větve za rušivé.

    • Po <n> hodinách, pokud <je název> větve aktualizován: Tato možnost vyprší aktuální stav zásad, když se chráněná větev aktualizuje, pokud je předávací build starší než zadaná prahová hodnota. Tato možnost představuje kompromis mezi tím, kdy při aktualizaci chráněné větve vždy vyžaduje sestavení a kdy to nikdy nevyžaduje. Tento výběr snižuje počet sestavení, když má vaše chráněná větev časté aktualizace.

    • Nikdy: Aktualizace chráněné větve nemění stav politiky. Tato hodnota snižuje počet sestavení, ale může způsobit problémy při uzavírání pull requestů, které nebyly nedávno aktualizovány.

  • Zadejte volitelný zobrazovaný název pro tuto zásadu sestavení. Tento název identifikuje zásadu na stránce Zásady větve. Pokud nezadáte zobrazovaný název, zásada použije název kanálu buildu.

  1. Zvolte Uložit.

Když vlastník PR odešle změny, které se úspěšně sestaví, stav politiky se aktualizuje.

Pokud máte zásadu sestavení pro Okamžitě když je <název větve> aktualizovaný nebo Po <n> hodinách, pokud byl <název větve> aktualizován, stav zásad se aktualizuje při aktualizaci chráněné větve, pokud předchozí build už není platný.

Vyžadovat kontroly stavu

Externí služby mohou použít rozhraní Status API pro PR k publikování podrobného stavu vašich žádostí o přijetí změn. Pravidla větve pro dodatečné služby umožňují těmto externím službám účastnit se pracovního postupu žádosti o přijetí změn a nastavit požadavky na pravidla.

Snímek obrazovky s možností Vyžadovat schválení externích služeb

Konfigurace zásad kontroly stavu:

  1. Ujistěte se, že služba může do Azure Repos publikovat stav pull requestu.
  2. V Zásadách větve v části Kontroly stavu vyberte +.
  3. V Stav ke kontrole vyberte ze seznamu zaúčtovaný šek. Pokud služba ještě nezveřejnila stav, zadejte hodnotu genre/name přímo.
  4. Nastavte požadavek na zásaduna Povinné nebo Volitelné.
  5. Volitelně můžete nakonfigurovat autorizovanou identitu, podmínky resetování, použitelnost zásad a filtr cesty.
    • Použijte Použít jako výchozí, pokud se má zásada použít hned po vytvoření pull requestu.
    • Použijte Conditional, pokud se má zásada použít až po zveřejnění prvního statusu.
  6. Vytvořte nebo aktualizujte pull request zaměřený na tuto větev a ověřte, že se zásada zobrazuje v části Zásady v PR.

Informace o integrovaných kontrolách Azure DevOps Services a jejich genre/name identifikátorech najdete v tématu Dostupné kontroly stavu žádosti o přijetí změn. Úplný návod k nastavení externí služby najdete v tématu Konfigurace zásad větve pro externí službu.

Pokud se v rozevíracím seznamu ještě nezobrazí nová integrace, publikujte stav jednou ze služby a pak přidejte zásadu genre/name nebo zadejte hodnotu přímo.

Automaticky zahrnout revidujících

Kontrolory můžete automaticky přidávat k žádostem o přijetí změn, které upravují soubory v konkrétních adresářích a souborech, nebo ke všem žádostem o přijetí změn v úložišti.

  1. + Vyberte tlačítko vedle automaticky zahrnutých recenzentů.

    Snímek obrazovky znázorňující Přidat požadované recenzenty.

  2. Vyplňte obrazovku Přidat novou politiku recenzenta.

    Snímek obrazovky znázorňující obrazovku Zásady pro přidání nového recenzenta

    • Přidejte lidi a skupiny do revidujících.

    • Vyberte Volitelné, pokud chcete přidat revidenty automaticky, ale nevyžadujete jejich schválení pro dokončení žádosti o přijetí změn.

      Nebo vyberte Povinné, pokud nelze žádosti o přijetí změn dokončit do:

      • Každý jednotlivec přidaný jako kontrolor změny schválí.
      • Změny schválí alespoň jedna osoba v každé skupině přidaná jako kontrolor.
      • Pokud je vyžadována pouze jedna skupina, minimální počet členů, které určíte, schválí změny.

    • Zadejte soubory a složky, které mají automaticky zahrnuty revizory. Nechte toto pole prázdné, aby byly vyžadovány schvalovatelé pro všechny pull requesty v této větvi.

    • Pokud mohou vlastníci žádostí o přijetí změn hlasovat pro schválení vlastních žádostí, aby splnili tuto politiku, vyberte Povolit žadatelům schválit vlastní změny.

    • Můžete zadat zprávu informačního kanálu o aktivitách, která se zobrazí v žádosti o přijetí změn.

  3. Zvolte Uložit.

Povolení obejití zásad v případě potřeby

V některých případech možná budete muset obejít požadavky zásad. Oprávnění k obcházení vám umožní přenést změny přímo do větve nebo dokončit pull requesty, které nevyhovují zásadám větvení. Oprávnění k obejití můžete udělit uživateli nebo skupině a určit rozsah těchto oprávnění pro celý projekt, úložiště nebo jednu větev.

Dvě oprávnění umožňují uživatelům obejít zásady větví různými způsoby:

  • Zásady obejití při dokončování žádostí o přijetí změn se vztahují pouze na dokončení žádosti o přijetí změn. Uživatelé s tímto oprávněním mohou provádět žádosti o přijetí změn i v případě, že žádosti o přijetí změn nesplňují zásady.

  • Obcházení zásad při přesunech se vztahuje na přesuny z místních úložišť a úpravy prováděné na webu. Uživatelé s tímto oprávněním můžou odesílat změny přímo do chráněných větví bez splnění požadavků zásad.

Snímek obrazovky znázorňující oprávnění k vynucování zásad obejití

Další informace o správě těchto oprávnění najdete v tématu Oprávnění Gitu.

Důležité

Při udělování možnosti obejít zásady, zejména na úrovni úložiště a projektu, buďte opatrní. Zásady jsou základním kamenem správy zabezpečeného a vyhovujícího zdrojového kódu.

Používejte filtry cest se zásadami větví

Několik zásad větvení podporuje filtry cest. Pokud nastavíte filtr cesty, zásada se vztahuje pouze na soubory, které odpovídají filtru. Pokud chcete zásadu použít pro všechny soubory ve větvi, nechte toto pole prázdné.

Můžete zadat absolutní cesty (cesta musí začínat znakem / nebo zástupným znakem) a zástupné znaky. Příklady:

  • /WebApp/Models/Data.cs
  • /WebApp/*
  • */Models/Data.cs
  • *.cs

Více cest můžete zadat pomocí ; oddělovače. Příklad:

  • /WebApp/Models/Data.cs;/ClientApp/Models/Data.cs

Pokud cesty opatříte předponou !, vyloučíte je, i kdyby jinak byly zahrnuty. Příklad:

  • /WebApp/*;!/WebApp/Tests/*zahrnuje všechny soubory kromě souborů v /WebApp/WebApp/Tests
  • !/WebApp/Tests/* určuje žádné soubory, protože nic není zahrnuto jako první.

Pořadí filtrů je významné. Použijte filtry zleva doprava.

Řešení problémů se zásadami větví

Můžu změny přesunout přímo do větví, které mají politiky větví?

Změny nemůžete odesílat přímo do větví s požadovanými zásadami větví, pokud nemáte oprávnění k obcházení zásad větví. Změny v těchto větvích můžete provádět pouze prostřednictvím pull requestů. Můžete změny nasdílet přímo do větví, které mají volitelné zásady, pokud nemají žádné povinné zásady větví.

Co je automatické dokončování?

Větve se zásadami větví nakonfigurovanými pro žádosti o přijetí změn mají tlačítko Nastavit automatické dokončování . Tuto možnost vyberte, pokud chcete nastavit, aby se žádost o přijetí změn automaticky dokončuje , jakmile splní všechny zásady. Automatické dokončování je užitečné, když neočekáváte žádné problémy se změnami.

Kdy jsou zkontrolovány podmínky zásad větve?

Server znovu vyhodnocuje zásady větví, když vlastníci požadavků na přijetí změn odešlou změny a když recenzenti hlasují. Pokud zásada aktivuje sestavení, stav sestavení se nastaví na čekání, dokud nebude sestavení dokončeno.

Mohu v zásadách větve používat definice sestavení XAML?

Ne, v zásadách větve nemůžete použít definice sestavení XAML.

Jaké zástupné znaky můžu použít pro požadované kontrolory kódu?

Jednoduché hvězdičky * odpovídají libovolnému počtu znaků, včetně lomítek / i zpětných lomítek \. Otazníky ? odpovídají jakémukoli jednomu znaku.

Příklady:

  • *.sql odpovídá všem souborům s příponou .sql .
  • /ConsoleApplication/* odpovídá všem souborům ve složce s názvem ConsoleApplication.
  • /.gitattributes odpovídá souboru.gitattributes* v kořenovém adresáři úložiště.
  • */.gitignore odpovídá jakémukoli souboru .gitignore v úložišti.

Rozlišují se malá a velká písmena v cestách požadovaných pro kontrolory kódu?

Ne, zásady větví nerozlišují malá a velká písmena.

Jak můžu nakonfigurovat více uživatelů jako požadovaných revidujících, ale vyžadovat, aby schvalovali jenom jeden z nich?

Uživatele můžete přidat do skupiny a potom přidat skupinu jako recenzenta. Každý člen skupiny může poté schválit splnění požadavku dané zásady.

Mám oprávnění k obejití zásad. Proč se stále zobrazují problémy ve stavu pull requestu?

Systém vždy vyhodnocuje nakonfigurované zásady pro změny v pull requestu. Pro uživatele, kteří mají oprávnění k obcházení zásad, má hlášený stav zásad pouze informativní charakter. Pokud uživatel s oprávněními k obejití schválí, stav selhání neblokuje dokončení pull requestu.

Proč nemůžu dokončit vlastní žádosti o přijetí změn, když nastavím možnost Povolit žadatelům schvalovat vlastní změny?

Zásady Vyžadovat minimální počet revidujících a automaticky zahrnuté zásady kontrolorů mají možnosti povolit žadatelům schválit vlastní změny. Nastavení se v každé zásadě vztahuje pouze na tuto zásadu. Nastavení nemá vliv na ostatní zásady.

Například váš pull request má nastavené následující politiky:

  • Vyžadovat minimální počet revidujících vyžaduje alespoň jednoho revidujícího.
  • Automaticky zahrnutí kontroloři vyžadují vás nebo tým, ve kterém jste, jako kontrolora.
  • Automaticky zahrnutý revidující má povoleno žadatelům schválit vlastní změny.
  • Vyžadovat minimální počet revidujících nemá povolení umožnit žadatelům schvalovat jejich vlastní změny.

V tomto případě vaše schválení splňuje podmínky pro automaticky zahrnuté kontrolory, ale ne splnění podmínky pro požadavek na minimální počet kontrolorů, takže nemůžete dokončit pull request.

Jiné zásady vám můžou bránit ve schvalování vlastních změn, a to i v případě, že je nastavena možnost Povolit žadateli schválit vlastní změny . Například zakázat uživateli, který naposledy odeslal změny, schvalovat vlastní změny.

Co se stane, když filtr cesty nezačíná na / nebo zástupný znak?

Cesta v filtrech cest, která nezačíná na / ani zástupným znakem, nemá žádný účinek. Filtr cesty se vyhodnotí tak, jako by tato cesta nebyla zadána. Taková cesta nemůže odpovídat / absolutní cestě k souboru, která začíná.

Použijte AI ke konfiguraci a správě zásad pro větve

Pokud nakonfigurujete Azure DevOps MCP Server, můžete použít přirozený jazyk ke shromažďování úložišť, větví, žádostí o přijetí změn a kontextu sestavení před aktualizací zásad větví ve službě Azure DevOps Services.

Server Azure DevOps MCP vyžaduje Azure DevOps Services, režim agenta v asistentovi AI a Node.js 20.0 nebo novější. Aktuální dokumentace MCP nepopisuje přímé akce čtení nebo zápisu zásad větve, takže k vytváření a aktualizaci zásad použijte webový portál Azure DevOps nebo Azure DevOps CLI.

Úkol Příklad výzvy
Seznam větví v úložišti List the branches in repo <Contoso.Web> in project <Contoso>
Zkontrolujte pull requesty před zpřísněním zásad What pull requests require my review in project <Contoso>?
Zkontrolujte pull request a propojené pracovní položky Get details for pull request <67> and its linked work items in project <Contoso>
Před nastavením povinného ověření sestavení zkontrolujte stav sestavení. Get the latest build status for pipeline <Contoso-CI> in project <Contoso>

Note

Pokud používáte Visual Studio Code, je režim agenta užitečný hlavně pro shromažďování kontextu projektu, který potřebujete, než aktualizujete zásady větve.

Související obsah

  • Last updated on