Implementace omezení slučování větví

Dokončeno

Omezení slučování větví v systémech správy verzí hostovaných v Azure DevOps a GitHubu jsou nezbytná pro řízení kvality kódu, usnadnění spolupráce a zvýšení stability v projektech pro vývoj softwaru. Pomáhají organizacím vynucovat kontroly kódu, ověřit úspěšné dokončení automatizovaných testů a zabránit vynucení vložení do určených větví. Tato omezení pomáhají zachovat integritu základu kódu, zabránit náhodným změnám a zajistit sloučení pouze ověřených a schválených změn do produkčních větví.

Obecné koncepty omezení slučování větví jsou nezávislé na platformě. I když se jejich implementace mírně liší mezi Azure DevOps a GitHubem, existuje také spousta podobností, které poskytují paritu funkcí mezi nimi.

Azure DevOps

VAzurech

Pokud chcete implementovat ochranu větví, přejděte do úložiště na portálu Azure DevOps a vyberte větev, na kterou chcete použít omezení sloučení. Případně můžete nastavit obor ochrany na aktuální a budoucí větve, které odpovídají zadanému vzoru. V rámci konfigurace ochrany můžete použít následující zásady větve:

  • Vyžadovat minimální počet revidujících: zajistí, že změny nelze sloučit bez požadovaného počtu schválení.
  • Kontrola propojených pracovních položek: podporuje sledovatelnost kontrolou propojených položek v žádostech o přijetí změn.
  • Kontrola řešení komentářů: Ověřuje, že všechny komentáře byly vyřešeny u žádostí o přijetí změn.
  • Omezit typy sloučení: Řídí historii větví omezením dostupných typů sloučení při dokončení žádostí o přijetí změn. To zahrnuje možnost selektivního povolení nebo zakázání následujících typů sloučení:
    • Základní sloučení (bez rychlého přeposlání): Zachovává historii přesně tak, jak se to stalo během vývoje.
    • Změna základu a rychlého přeposlání: vytvoří lineární historii tak, že přehraje potvrzení zdrojové větve do cíle bez potvrzení sloučení.
    • Squash merge: Vytvoří lineární historii tím, že zkondenzuje potvrzení zdrojové větve do jednoho nového potvrzení v cílové větvi.
    • Rebase with merge commit: Vytvoří pololineární historii tak, že přehraje potvrzení zdrojové větve do cíle a pak vytvoří potvrzení sloučení.

Volitelně můžete nakonfigurovat následující omezení:

  • Ověření sestavení: Ověřuje kód před sloučením a sestavením změn žádostí o přijetí změn.
  • Kontroly stavu: K dokončení žádostí o přijetí změn vyžadují další služby po úspěšném stavu. Kontroly stavu jsou automatizované úlohy, které se aktivují během procesu žádosti o přijetí změn a ověřují určitá kritéria před povolením sloučení žádosti o přijetí změn do cílové větve. V Azure DevOps jsou kontroly stavu přidružené ke kanálům buildu a kanálům verze.
  • Automaticky zahrnout revidujícím: Určete revidujícím kód, které se mají automaticky zahrnout, když žádosti o přijetí změn změní určité oblasti kódu.

Máte také možnost uzamknout větev a efektivně ji tak, aby byla jen pro čtení.

Všimněte si, že Azure DevOps nabízí dvě možnosti, jak obejít požadavky zásad pro úložiště. Pokud je chcete implementovat, musíte změnit výchozí konfiguraci zabezpečení úložiště nastavením oprávnění k provedení následujících akcí, které chcete povolit:

  • Při dokončování žádostí o přijetí změn zásady obejití.
  • Vynechat zásady při nabízení

Je nezbytné zajistit, aby tato oprávnění byla udělena pouze určeným jednotlivcům, kteří chápou důsledky těchto akcí v souladu s organizačními standardy a mohou vykonávat řádné úsudek ohledně jejich použití.

GitHubu

Na GitHubu můžete implementovat omezení slučování větví pomocí pravidel ochrany větví. Pravidla ochrany větví definují, jestli spolupracovníci můžou odstranit nebo vynutit vložení do větve, a nastavovat požadavky pro jakékoli zápisy do větve, například předávání kontrol stavu nebo historii lineárních potvrzení. Stejně jako u Azure DevOps je můžete použít na konkrétní větve na základě shody vzorů názvů.

Pokud chcete implementovat pravidla ochrany větví, přejděte do úložiště ve webovém rozhraní GitHubu, na kartě Nastavení a v navigační nabídce vyberte položku nabídky Větve. To vám umožní přístup ke konfiguraci pravidel služby Branch Protection. V rámci konfigurace ochrany můžete použít následující pravidla:

  • Před sloučením vyžadovat žádost o přijetí změn: Před sloučením změn musí přispěvatelé odesílat žádosti o přijetí změn ke kontrole a schválení.
  • Vyžadovat, aby kontroly stavu prošly před sloučením: Určuje kontroly stavu, které musí proběhnout před povolením sloučení. Pokud je tato možnost povolená, musí se potvrzení nejprve odeslat do jiné větve a potom je sloučit nebo odeslat přímo do větve, která odpovídá tomuto pravidlu po uplynutí kontrol stavu.
  • Před sloučením vyžadovat řešení konverzace: před sloučením žádostí o přijetí změn se vyřeší všechny diskuze a komentáře související se změnami kódu.
  • Vyžadování podepsaných potvrzení: pověření, která potvrdí vložení do chráněných větví, jsou podepsána ověřenými podpisy, vylepšením zabezpečení a zajištění pravosti příspěvků kódu.
  • Vyžadovat lineární historii: zabraňuje potvrzení sloučení v chráněných větvích, vynucuje lineární historii, což usnadňuje sledování a v případě potřeby převrácení změn. To znamená, že všechny žádosti o přijetí změn musí používat sloučení squashů nebo sloučení s rebase.
  • Před sloučením vyžadovat úspěšné nasazení: Určuje, že změny navržené v žádostech o přijetí změn se před integrací do základu kódu důkladně testují a ověřují.
  • Zamknout větev: jako ekvivalent Azure DevOps omezuje přístup k zápisu do větve a z ní dělá jen pro čtení.
  • Nepovolujte obejití výše uvedených nastavení: eliminuje možnost obejití ostatních pravidel správci a uživateli udělili oprávnění k obejití větví.
  • Povolit vynucené nabízení: Povolte uživatelům s oprávněními nabízených oznámení vynucení změn. Stejně jako u Azure DevOps se jedná pouze o nouzové opatření.
  • Povolit odstranění: Umožňuje uživatelům s nabízenými oprávněními odstranit chráněné větve. I když tato flexibilita může zjednodušit správu větví, představuje také riziko náhodného nebo škodlivého odstranění větví a mělo by být pečlivě řízeno, aby se zabránilo ztrátě dat a zachování integrity úložiště.