Nasazení artefaktů žádostí o přijetí změn s využitím klasických kanálů verze
Azure DevOps Services | Azure DevOps Server 2022 – Azure DevOps Server 2019
Žádosti o přijetí změn poskytují efektivní způsob kontroly změn kódu před sloučením do základu kódu. Tyto změny ale můžou představovat problémy, které můžou být složité najít bez sestavení a nasazení aplikace do konkrétního prostředí. Triggery žádostí o přijetí změn umožňují nastavit sadu kritérií, která musí být splněna před nasazením kódu. V tomto článku se dozvíte, jak nastavit triggery žádostí o přijetí změn pomocí Azure Repos a GitHubu pro nasazení artefaktu sestavení.
Požadavky
- Zdrojový kód hostovaný v Azure Repos nebo GitHubu Použijte ukázkovou aplikaci pipelines-dotnet-core a vytvořte úložiště, pokud ho ještě nemáte.
- Funkční kanál buildu pro vaše úložiště.
- Kanál verze Classic. Pokud kanál verze Classic ještě nemáte, nastavte ho.
Nasazení žádosti o přijetí změn
S triggery žádostí o přijetí změn se při každé vyvolání nové žádosti o přijetí změn pro určenou větev automaticky aktivuje vydání, které spustí nasazení do určených prostředí. Stav nasazení se pak zobrazí na stránce žádosti o přijetí změn. Triggery žádostí o přijetí změn vám můžou pomoct udržovat lepší kvalitu kódu, vydávat s větší jistotou a zjišťovat případné problémy v rané fázi vývojového cyklu.
Nastavení nasazení žádostí o přijetí změn je dvoustupňový proces, nejprve musíme nastavit trigger žádosti o přijetí změn a pak nastavit zásady větví (Azure Repos) nebo kontroly stavu (GitHub) pro naše kanály verze.
Vytvoření triggeru žádosti o přijetí změn
Trigger žádosti o přijetí změn vytvoří vydání pokaždé, když je k dispozici nový artefakt sestavení.
Přejděte do projektu Azure DevOps, vyberte Pipelines>Release a pak vyberte kanál verze.
V části Artefakty vyberte ikonu triggeru průběžného nasazování.
Výběrem přepínacího tlačítka povolte trigger žádosti o přijetí změn.
V rozevírací nabídce vyberte cílovou větev .
Pokud chcete nasadit aplikaci do konkrétní fáze, musíte explicitně vyjádřit výslovný souhlas s danou fází. V části Fáze se zobrazují fáze, které jsou povolené pro nasazení žádostí o přijetí změn.
Pokud chcete vyjádřit výslovný souhlas s nasazením žádosti o přijetí změn, vyberte ikonu Podmínek před nasazením pro vaši konkrétní fázi a pak vyberte Aktivační události>po vydání. Nakonec vyberte přepínač nasazení žádosti o přijetí změn a povolte ho.
Důležité
Povolení automatického nasazení žádostí o přijetí změn pro produkční fáze se nedoporučuje.
Nastavení zásad větví pro Azure Repos
Zásady větve můžete použít k implementaci seznamu kritérií, která musí být splněna, aby byla žádost o přijetí změn sloučena.
Přejděte do svého projektu a pak vyberte Větve repos>pro přístup k seznamu větví pro vaše úložiště.
Vyberte místní nabídku pro příslušnou větev
...a pak vyberte Zásady větve.
Vyberte Přidat zásadu stavu a pak v rozevírací nabídce vyberte Stav, který chcete zkontrolovat. Vyberte stav odpovídající definici vydané verze a pak vyberte Uložit.
Poznámka:
Aby bylo možné získat seznam stavů, měla by definice vydané verze běžet alespoň jednou s povoleným triggerem žádosti o přijetí změn. Další podrobnosti najdete v tématu Konfigurace zásad větve pro externí službu .
Když přidáte novou zásadu stavu, uživatelé nebudou moct do žádosti o přijetí změn sloučit žádné změny cílové větve bez stavu "úspěch".
Stav zásad můžete zobrazit na stránce Přehled žádostí o přijetí změn. V závislosti na nastavení zásad můžete zobrazit stav publikované verze v části Povinné, Volitelné nebo Stav . Stav verze se aktualizuje při každém aktivaci kanálu.
Nastavení kontrol stavu pro úložiště GitHub
Povolení kontrol stavu úložiště GitHub umožňuje správci zvolit, která kritéria musí být splněna před sloučením žádosti o přijetí změn do cílové větve.
Poznámka:
Kontroly stavu se publikují na vaši žádost o přijetí změn až po spuštění kanálu verze aspoň jednou s povolenou podmínkou nasazení žádosti o přijetí změn. Další podrobnosti najdete v pravidlech ochrany větví.
Kontroly stavu můžete zobrazit v žádosti o přijetí změn na kartě Konverzace .
