Vysvětlení ověřování žádostí o přijetí změn
Když používáte žádosti o přijetí změn, můžete zajistit, aby někdo jiný zkontroloval všechny aktualizace vašich nasazení Azure. Často je ale užitečné mít také automatizované kontroly spuštěné na změnách kódu. V této lekci se dozvíte, jak můžete pomocí automatizovaného ověřování žádostí o přijetí změn a kontrol zvýšit důvěru vašeho týmu ve změnách kódu.
Ověření žádosti o přijetí změn
Při kontrole žádosti o přijetí změn pro kód Bicep můžete mít několik běžných kroků, kterými projdete posouzením změny. Mezi tyto kroky může patřit:
- Kontrola, jestli soubor Bicep obsahuje nějaké chyby nebo upozornění na linter
- Zajištění, aby všechny prostředky dříve definované v souboru Bicep fungovaly.
- Testování všech nově definovaných prostředků, aby se zajistilo, že se úspěšně nasadí a že budou fungovat podle očekávání.
Ověření žádosti o přijetí změn zahrnuje automatizaci některých z těchto aktivit. Když automatizujete kontroly žádostí o přijetí změn, můžou revidujícím trávit čas na další důležitější kroky kontroly, například zajistit, aby kód splňoval standardy kvality vašeho týmu a dosáhli obchodního cíle.
V pracovním postupu GitHub Actions můžete definovat triggery, které během procesu žádosti o přijetí změn vyvolávají pracovní postup v určitých bodech, včetně vytvoření, aktualizace, sloučení nebo uzavření žádosti o přijetí změn.
Testování kódu Bicep v pracovním postupu ověření žádosti o přijetí změn
V předchozích modulech jste se naučili vytvářet komplexní pracovní postupy GitHub Actions pro lintování, ověřování, nasazování a testování změn infrastruktury Azure, včetně napříč několika prostředími. Tyto pracovní postupy se spustí po sloučení změn v hlavní větvi.
V pracovním postupu ověření žádosti o přijetí změn můžete také spustit mnoho stejných aktivit. Příklad:
- Lintování kódu Bicep pomáhá zajistit, aby byl kód sémanticky správný a že se řídí některými doporučenými postupy Bicep podle směrného plánu.
- Předběžné ověření vám pomůže vytvořit jistotu, že se kód úspěšně nasadí, aniž byste museli soubor skutečně nasazovat. V závislosti na typu prostředku může předběžné ověření hledat problémy, jako jsou neplatné názvy prostředků, neplatné oblasti pro konkrétní prostředky a jestli jste zadali konfiguraci, která se nedá úspěšně nasadit.
- Citlivostní kontrola, která vypíše změny, které se v prostředí Azure provedou v důsledku nasazení.
- Nasazení, aby se prostředky skutečně nasadily a zajistily, že nedojde k žádným chybám nasazení.
- Testování prostředků po nasazení, abyste měli jistotu, že jsou nakonfigurované podle vašich obchodních požadavků.
Pracovní postup ověření žádosti o přijetí změn je normální pracovní postup GitHub Actions, takže může spouštět všechny tyto úlohy. Je ale vhodné přemýšlet o typech kontrol, které mají smysl spouštět v rámci žádosti o přijetí změn. Řada zde uvedených aktivit ověřování vyžaduje přístup k prostředí Azure. Například operace citlivostní operace porovnává prostředky definované v souborech Bicep s prostředky ve vašem předplatném Azure. Je vhodné spustit toto porovnání s produkčním prostředím, ale protože tím dojde k dalšímu riziku, nemusíte být obeznámeni se spouštěním operací s produkčním prostředím z pracovního postupu navrženého pro kód, který ještě není dokončený nebo sloučený.
V tomto modulu přidáte do pracovního postupu ověření žádosti o přijetí změn dva druhy kontrol:
- Na lintování kódu Bicep spusťte počáteční sadu kontrol.
- Nasazení kódu do zcela nového dočasného prostředí
Tyto dvě aktivity nevyžadují připojení k produkčnímu prostředí Azure ani k žádnému z běžných neprodukčních prostředí, jako je testování, kontrola kvality nebo příprava. Když tyto dvě aktivity spustíte, můžete si stále vytvořit dobrou důvěru ve změny kódu, abyste je mohli sloučit do hlavní větve úložiště.
Kontroly jsou užitečné pro revidujícím, protože šetří čas, který by jinak strávil spouštěním aktivit ručně. Kontroly jsou také užitečné pro vás jako autor žádosti o přijetí změn, protože je můžete použít k získání počátečního přehledu o tom, jak budou vaše změny fungovat později v procesu nasazení.
Ve vlastních pracovních postupech ověření žádostí o přijetí změn se můžete rozhodnout rozšířit kontroly ověření o další aktivity.
Triggery životního cyklu žádostí o přijetí změn
Žádost o přijetí změn na GitHubu může projít mnoha různými událostmi životního cyklu. Například se otevře žádost o přijetí změn. Autor pak může odeslat změny do zdrojové větve (synchronizovat), což má vliv na obsah žádosti o přijetí změn. V dalším kroku můžete žádost o přijetí změn sloučit, zavřít , aniž byste ji sloučili, a dokonce ji znovu otevřít v budoucnu.
Pomocí GitHub Actions můžete definovat triggery pracovního postupu, které reagují na některou z těchto událostí. Můžete například definovat pracovní postup, který se spustí automaticky při každém otevření, synchronizaci nebo opětovném otevření žádosti o přijetí změn zadáním triggeru pull_request bez jakékoli další konfigurace:
on: pull_request
Můžete také zadat události žádosti o přijetí změn, které aktivují pracovní postup. Například následující pracovní postup se spustí automaticky při zavření žádosti o přijetí změn:
on:
pull_request:
types: [closed]
Důležité
Pokud v žádosti o přijetí změn dojde ke konfliktům při sloučení, pracovní postup se nespustí. Potřebujete vyřešit konflikt a odeslat řešení, aby se pracovní postup mohl spustit.
Kontroly stavu žádosti o přijetí změn
Výsledky pracovního postupu žádosti o přijetí změn se zobrazují na stránce podrobností žádosti o přijetí změn jako kontroly. Kontroly umožňují autorům a recenzentům rychle získat zpětnou vazbu o tom, jestli byly automatizované aktivity úspěšné nebo neúspěšné, jak je znázorněno v následujícím příkladu:
Ve výchozím nastavení je možné žádost o přijetí změn sloučit i v případě selhání kontroly. Možná to nechcete povolit, takže můžete nakonfigurovat pravidla ochrany větví tak, aby vynucovala, že konkrétní kontroly musí proběhnout úspěšně, než bude možné žádost o přijetí změn sloučit.
Aktualizace souborů
Po vytvoření žádosti o přijetí změn je běžné, že autor musí provádět aktualizace. Příklad:
- Kontrolor může autora požádat, aby v kódu udělal změny.
- Pokud automatická kontrola selže, může autor změnit kód, aby problém vyřešil, a pak změny potvrdit a odeslat.
Pomocí triggeru pull_request můžete nakonfigurovat pracovní postup ověření tak, aby se spustil při každé aktualizaci zdrojové větve. Výsledky nejnovějšího spuštění pracovního postupu se zobrazují na stránce s podrobnostmi žádosti o přijetí změn.
Opakovaně použitelné pracovní postupy
Pokud se podíváte na seznam možných kontrol ověření žádostí o přijetí změn, všimnete si, že se jedná o stejné kroky, které byste spustili v běžném pracovním postupu nasazení. Abyste se vyhnuli opakování, je vhodné použít opakovaně použitelné pracovní postupy GitHubu.
Můžete definovat opakovaně použitelné pracovní postupy pro každou z úloh, které budete používat v různých definicích pracovního postupu. V dalším cvičení se dozvíte, jak to udělat.
Návrhy žádostí o přijetí změn
Jako autor byste obvykle otevřeli žádost o přijetí změn, až budete připraveni na kontrolu, schválení a sloučení změn. V průběhu psaní kódu ale může být užitečné získat přístup k automatizovaným kontrolám ověření žádostí o přijetí změn, i když ještě nejste připravení na sloučení změn.
Když otevřete žádost o přijetí změn na GitHubu, můžete ji označit jako koncept. GitHub spouští všechny stejné automatizované kontroly a revidujícím můžou dál poskytovat zpětnou vazbu. Když je ale vaše žádost o přijetí změn ve stavu konceptu, je jasné, že práce ještě není připravená na úplnou kontrolu a nedá se sloučit.
Zejména je běžné vytvářet koncepty žádostí o přijetí změn, když pracovní postup ověření žádosti o přijetí změn vytváří dočasné prostředí, protože můžete zobrazit náhled změn v živém pracovním prostředí. S tím, jak budete dál nasdílovat změny, se dočasné prostředí aktualizuje, aby zahrnovalo nejnovější změny.