Cvičení spolupráce Azure Repos s žádostmi o přijetí změn
Problémy s kódem, které jsou nalezeny dříve, jsou jednodušší a levnější opravit. Vývojové týmy se proto snaží co nejvíce nasdílet kontroly kvality kódu do procesu vývoje.
Jak název napovídá, zásady větví poskytují sadu předefinovaných zásad, které se dají použít na větve na serveru.
Všechny změny, které se odsílají do větví serveru, musí tyto zásady dodržovat, aby bylo možné změny přijmout.
Zásady představují skvělý způsob, jak vynutit kvalitu kódu vašeho týmu a standardy správy změn. V tomto receptu se dozvíte, jak nakonfigurovat zásady větví v hlavní větvi.
Příprava
Předefinované zásady větve zahrnují několik zásad, jako je ověření sestavení a vynucení strategie sloučení. Zaměříme se jenom na zásady větví potřebné k nastavení pracovního postupu kontroly kódu v tomto receptu.
Jak to udělat
Otevřete zobrazení větví pro úložiště myWebApp Git na týmovém portálu bez omezení částí. Vyberte hlavní větev a v místní nabídce pro stažení zvolte Zásady větve:
V zobrazení zásad zobrazuje předem stanovené zásady. Nastavte minimální počet revidujících na 1:
Možnost Povolit žadateli schvalovat vlastní změny umožňuje žadateli, aby své změny schválil sám.
I když to může být přijatelné pro vyspělé týmy, obecně by se mělo vyhnout.
Použijte zásadu kontroly se zásadami řešení komentářů. Umožňuje vynutit, aby se komentáře ke kontrole kódu vyřešily před přijetím změn. Žadatel může napsat zpětnou vazbu z komentáře a vytvořit novou pracovní položku a vyřešit změny. Alespoň zaručuje, že komentáře ke kontrole kódu se neztratí s přijetím kódu do hlavní větve:
Požadavek vystiuje změnu kódu v týmovém projektu. Pokud pracovní položka aktivovala tuto změnu, není propojená se změnou, bude obtížné pochopit, proč byla v průběhu času provedena. Je zvlášť užitečné při kontrole historie změn. Nakonfigurujte zásadu Kontrola propojených pracovních položek tak, aby blokovala změny, které nemají propojenou pracovní položku:
Vyberte možnost automatického zahrnutí revidujících při automatickém vyvolání žádosti o přijetí změn. Namapovat, kteří revidoři se přidají, můžete namapovat podle oblasti změněného kódu:
Jak to funguje
Když jsou zásady větví zavedené, hlavní větev je teď plně chráněná.
Jediným způsobem, jak odeslat změny do hlavní větve, je nejprve provést změny v jiné větvi a pak vytvořit žádost o přijetí změn, aby se aktivoval pracovní postup přijetí změn.
Zvolte, že chcete vytvořit novou větev z jednoho z existujících uživatelských scénářů v centru pracovních položek.
Vytvořením nové větve z pracovní položky se tato pracovní položka automaticky propojila s větví.
Volitelně můžete do pracovního postupu vytvoření zahrnout více než jednu pracovní položku s větví:
Předpona v názvu při vytváření větve, aby se vytvořila složka pro větev, ve které se má větev vrátit.
V předchozím příkladu se větev přesune do složky. Je to skvělý způsob, jak uspořádat větve v zaneprázdněných prostředích.
S nově vytvořenou větví vybranou na webovém portálu upravte soubor HomeController.cs tak, aby zahrnoval následující fragment kódu a potvrďte změny do větve.
Na následujícím obrázku uvidíte, že změny můžete po úpravě souboru potvrdit přímo kliknutím na tlačítko potvrzení.
Ovládací prvek cesta k souboru na týmovém portálu podporuje vyhledávání.
Začněte psát cestu k souboru, abyste viděli všechny soubory v úložišti Git v tomto adresáři, počínaje těmito písmeny, které se zobrazují v rozevíracím seznamu výsledků hledání v cestě k souboru.
Editor kódu na webovém portálu má v Azure DevOps Serveru několik nových funkcí, jako je podpora párování závorek a přepínání prázdných znaků.
Paletu příkazů můžete načíst tak, že ji stisknete. Kromě mnoha dalších nových možností teď můžete soubor přepnout pomocí minimapy, sbalení a rozbalení a dalších standardních operací.
Pokud chcete tyto změny odeslat z nové větve do hlavní větve, vytvořte žádost o přijetí změn ze zobrazení žádosti o přijetí změn.
Vyberte novou větev jako zdroj a hlavní větev jako cílovou větev.
Nový formulář žádosti o přijetí změn podporuje Markdown, takže můžete přidat popis pomocí syntaxe markdownu.
Okno popisu také podporuje @zmínky a # pro propojení pracovních položek:
Vytvoří se žádost o přijetí změn; stránka přehledu shrnuje změny a stav zásad.
Na kartě Soubory se zobrazí seznam změn a rozdíl mezi předchozími a aktuálními verzemi.
Všechny aktualizace vložené do souborů kódu se zobrazí na kartě Aktualizace a na kartě Potvrzení se zobrazí seznam všech potvrzení:
Otevřete kartu Soubory: toto zobrazení podporuje komentáře ke kódu na úrovni řádku, úrovni souboru a celkově.
Komentáře podporují znak @ pro zmínky i # pro propojení pracovních položek a text podporuje syntaxi markdownu:
Komentáře ke kódu se uchovávají v pracovním postupu žádosti o přijetí změn; komentáře kódu podporují více iterací recenzí a dobře fungují s vnořenými odpověďmi.
Zásady revidujících umožňují v rámci přijetí změn pracovní postup kontroly kódu.
Je to skvělý způsob, jak tým spolupracovat na všech změnách kódu, které byly vloženy do hlavní větve.
Když požadovaný počet revidujících žádost o přijetí změn schválí, můžete ji dokončit.
Po kontrole můžete také označit žádost o přijetí změn, která se má automaticky dokončovat. Po úspěšném kompilaci všech zásad se automaticky dokončí žádosti o přijetí změn.
Další možnosti
Už jste někdy byli ve stavu, kdy byla větev omylem odstraněna? Není snadné zjistit, co se stalo.
Azure DevOps Server teď podporuje vyhledávání odstraněných větví. Pomůže vám pochopit, kdo ho odstranil a kdy. Rozhraní také umožňuje znovu vytvořit větev.
Odstraněné větve se zobrazí jenom v případě, že je hledáte podle jejich přesného názvu, abyste z výsledků hledání vyřízli šum.
Pokud chcete vyhledat odstraněnou větev, zadejte celý název větve do pole pro vyhledávání větví. Hledání vrátí všechny existující větve, které odpovídají hledanému textu.
V seznamu odstraněných větví se také zobrazí možnost vyhledat přesnou shodu.
Pokud se najde shoda, uvidíte, kdo ji odstranil a kdy. Větev můžete také obnovit. Obnovením odstraněnou větev znovu vytvoříte v potvrzení, na které naposledy ukazovala.
Zásady a oprávnění ale neobnoví.