Sdílet prostřednictvím

Výběr nejlepší možnosti pracovního postupu CI/CD infrastruktury pro vás

  • Článek

Cílem tohoto článku je prezentovat vývojáře prostředků infrastruktury s různými možnostmi vytváření procesů CI/CD v Prostředcích infrastruktury na základě běžných scénářů zákazníků. Tento článek se zaměřuje na průběžné nasazování (CD) procesu CI/CD. Diskuzi o části kontinuální integrace (CI) najdete v tématu Správa větví Gitu.

I když tento článek popisuje několik různých možností, mnoho organizací používá hybridní přístup.

Požadavky

Pokud chcete získat přístup k funkci kanálů nasazení, musíte splnit následující podmínky:

Proces vývoje

Proces vývoje je stejný ve všech scénářích nasazení a je nezávislý na tom, jak vydávat nové aktualizace do produkčního prostředí. Když vývojáři pracují se správou zdrojového kódu, musí pracovat v izolovaném prostředí. V prostředcích infrastruktury může být toto prostředí buď integrované vývojové prostředí (IDE) na místním počítači (například Power BI Desktop nebo VS Code), nebo jiný pracovní prostor v prostředcích infrastruktury. Informace o různýchaspektech

Diagram znázorňující, jak proces vývoje funguje

Proces vydávání verzí

Proces vydání se spustí, jakmile se dokončí nové aktualizace a žádost o přijetí změn se sloučí do sdílené větve týmu (například Main, Dev atd.). Od tohoto okamžiku existují různé možnosti sestavení procesu vydání v prostředcích infrastruktury.

Možnost 1 – Nasazení založená na Gitu

Diagram znázorňující, jak funguje nasazení založené na Gitu

Díky této možnosti pocházejí všechna nasazení z úložiště Git. Každá fáze kanálu verze má vyhrazenou primární větev (v diagramu jsou tyto fáze dev, test a Prod), která podává příslušný pracovní prostor v prostředcích infrastruktury.

Po schválení a sloučení žádosti o přijetí změn do vývojové větve:

  1. Kanál verze se aktivuje k aktualizaci obsahu pracovního prostoru Pro vývoj . Tento proces může také zahrnovat kanál buildu pro spouštění testů jednotek, ale skutečné nahrávání souborů se provádí přímo z úložiště do pracovního prostoru pomocí rozhraní API Gitu infrastruktury. Možná budete muset volat jiná rozhraní API prostředků infrastruktury pro operace po nasazení, které nastavují konkrétní konfigurace pro tento pracovní prostor nebo ingestují data.
  2. Pak se vytvoří žádost o přijetí změn do testovací větve. Ve většině případů se žádost o přijetí změn vytvoří pomocí větve vydané verze, která může vybrat obsah, který se má přesunout do další fáze. Žádost o přijetí změn by měla obsahovat stejné procesy kontroly a schválení jako všechny ostatní procesy ve vašem týmu nebo organizaci.
  3. K aktualizaci pracovního prostoru testování se aktivuje jiný kanál buildu a verze, který se podobá procesu popsanému v prvním kroku.
  4. Žádost o přijetí změn se vytvoří do větve Prod pomocí procesu podobného procesu popsanému v kroku 2.
  5. K aktualizaci pracovního prostoru Prod se aktivuje jiný kanál buildu a verze, který se podobá procesu popsanému v prvním kroku.

Kdy byste měli zvážit použití možnosti č. 1?

  • Pokud chcete úložiště Git používat jako jediný zdroj pravdy a původ všech nasazení.
  • Když váš tým sleduje Gitflow jako strategii větvení, včetně několika primárních větví.
  • Nahrávání z úložiště přejde přímo do pracovního prostoru, protože před nasazením nepotřebujeme vytvářet prostředí pro změnu souborů. Můžete to změnit voláním rozhraní API nebo spuštěním položek v pracovním prostoru po nasazení.

Možnost 2 – Nasazení založená na Gitu s využitím prostředí sestavení

Diagram znázorňující tok nasazení založeného na Gitu pomocí prostředí sestavení

S touto možností pocházejí všechna nasazení ze stejné větve úložiště Git (Main). Každá fáze kanálu verze má vyhrazený kanál buildu a verze . Tyto kanály můžou pomocí prostředí sestavení spouštět testy jednotek a skripty, které mění některé definice v položkách předtím, než se nahrají do pracovního prostoru. Můžete například chtít změnit připojení ke zdroji dat, připojení mezi položkami v pracovním prostoru nebo hodnoty parametrů pro úpravu konfigurace pro správnou fázi.

Po schválení a sloučení žádosti o přijetí změn do vývojové větve:

  1. Kanál buildu se aktivuje k aktivaci nového prostředí sestavení a spuštění testů jednotek pro vývojovou fázi. Potom se aktivuje kanál verze, který nahraje obsah do prostředí sestavení, spustí skripty pro změnu některé konfigurace, upraví konfiguraci ve fázi vývoje a použije rozhraní API pro definici položky aktualizace Fabric k nahrání souborů do pracovního prostoru.
  2. Po dokončení tohoto procesu, včetně ingestování dat a schválení od správců vydaných verzí, je možné vytvořit další kanály buildu a verze pro testovací fázi. Tyto fáze se vytvářejí v procesu podobném tomu, co je popsáno v prvním kroku. V případě testovací fáze mohou být po nasazení vyžadovány další automatizované nebo ruční testy, aby bylo možné ověřit, že změny jsou připravené k vydání do fáze Prod .
  3. Po dokončení všech automatizovaných a ručních testů může správce verzí schválit a spustit kanály sestavení a verze do fáze Prod . Vzhledem k tomu, že fáze Prod má obvykle různé konfigurace než fáze testování nebo vývoje , je důležité také otestovat změny po nasazení. Nasazení by také mělo na základě změny aktivovat jakýkoli další příjem dat, aby se minimalizovala potenciální dostupnost pro uživatele.

Kdy byste měli zvážit použití možnosti č. 2?

  • Pokud chcete Git použít jako jediný zdroj pravdy a původ všech nasazení.
  • Když váš tým jako strategii větvení sleduje pracovní postup založený na kmeni.
  • Před nasazením potřebujete prostředí sestavení (s vlastním skriptem) ke změně atributů specifických pro pracovní prostor, například connectionId a lakehouseId.
  • K načtení obsahu položek z Gitu potřebujete kanál verze (vlastní skript) a volání odpovídajícího rozhraní API položky infrastruktury pro vytváření, aktualizaci nebo odstraňování upravených položek infrastruktury.

Možnost 3 – Nasazení pomocí kanálů nasazení Fabric

Diagram znázorňující tok nasazení založeného na Gitu pomocí kanálů nasazení

Díky této možnosti je Git připojený jenom do fáze vývoje . Ve fázi vývoje probíhá nasazení přímo mezi pracovními prostory dev/test/Prod pomocí kanálů nasazení Fabric. I když je samotný nástroj interní pro Prostředky infrastruktury, můžou vývojáři použít rozhraní API kanálů nasazení k orchestraci nasazení jako součásti kanálu verze Azure nebo pracovního postupu GitHubu. Tato rozhraní API umožňují týmu vytvořit podobný proces sestavení a vydání jako v jiných možnostech pomocí automatizovaných testů (které je možné provést v samotném pracovním prostoru nebo před fází vývoje ), schválení atd.

Po schválení a sloučení žádosti o přijetí změn do hlavní větve:

  1. Aktivuje se kanál buildu , který nahraje změny do vývojové fáze pomocí rozhraní API Gitu infrastruktury. V případě potřeby může kanál aktivovat další rozhraní API pro spuštění operací/testů po nasazení ve fázi vývoje .
  2. Po dokončení nasazení pro vývoj se spustí kanál verze, ve které se nasadí změny z fáze vývoje na testovací fázi. Automatizované a ruční testy by se měly provést po nasazení, aby se zajistilo, že se změny dobře testují před dosažením produkčního prostředí.
  3. Po dokončení testů a správce verzí schválí nasazení do fáze Prod , vydání verze prod se spustí a dokončí nasazení.

Kdy byste měli zvážit použití možnosti č. 3?

  • Pokud používáte správu zdrojového kódu jenom pro účely vývoje a dáváte přednost nasazení změn přímo mezi fázemi kanálu verze.
  • Když pravidla nasazení, automatické vazby a další dostupná rozhraní API jsou dostačující ke správě konfigurací mezi fázemi kanálu verze.
  • Pokud chcete použít další funkce kanálů nasazení Fabric, jako je zobrazení změn v prostředcích infrastruktury, historie nasazení atd.
  • Zvažte také, že nasazení v kanálech nasazení Fabric mají lineární strukturu a vyžadují další oprávnění k vytvoření a správě kanálu.

Možnost 4 – CI/CD pro nezávislé výrobce softwaru v Prostředcích infrastruktury (správa více zákazníků a řešení)

Diagram znázorňující tok nasazení založeného na Gitu pro nezávislé výrobce softwaru

Tato možnost se liší od ostatních. Nejrelevavantnější je pro nezávislé dodavatele softwaru (ISV), kteří vytvářejí aplikace SaaS pro své zákazníky nad platformou Fabric. Nezávislí výrobci softwaru mají obvykle samostatný pracovní prostor pro každého zákazníka a můžou mít až několik stovek nebo tisíc pracovních prostorů. Pokud je struktura analýzy poskytovaná každému zákazníkovi podobná a předem připravená, doporučujeme mít centralizovaný proces vývoje a testování, který se rozdělí na každého zákazníka pouze ve fázi Prod .

Tato možnost je založená na možnosti 2. Jakmile se žádost o přijetí změn schválí a sloučí:

  1. Kanál buildu se aktivuje k aktivaci nového prostředí sestavení a spuštění testů jednotek pro vývojovou fázi. Po dokončení testů se aktivuje kanál verze . Tento kanál může nahrát obsah do prostředí sestavení, spustit skripty, které změní konfiguraci, upravit konfiguraci do vývojové fáze a pak pomocí rozhraní API pro aktualizaci položek infrastruktury nahrát soubory do pracovního prostoru.
  2. Po dokončení tohoto procesu, včetně ingestování dat a schválení od správců vydaných verzí, se může spustit další kanály buildu a verze pro testovací fázi. Tento proces se podobá procesu popsanému v prvním kroku. V případě fáze testování mohou být po nasazení vyžadovány další automatizované nebo ruční testy, aby bylo možné ověřit, že změny jsou připravené k vydání do fáze Prod ve vysoké kvalitě.
  3. Jakmile všechny testy projdou a proces schválení dokončí, nasazení pro zákazníky s prod může začít. Každý zákazník má vlastní verzi s vlastními parametry, aby se jeho konkrétní konfigurace a datové připojení mohly provádět v pracovním prostoru příslušného zákazníka. Ke změně konfigurace může dojít prostřednictvím skriptů v prostředí sestavení nebo pomocí rozhraní API po nasazení. Všechny verze můžou probíhat paralelně, protože spolu nesouvisí ani vzájemně nezávisí.

Kdy byste měli zvážit použití možnosti č. 4?

  • Jste výrobce softwaru, který vytváří aplikace nad prostředky infrastruktury.
  • Ke správě víceklientské architektury aplikace používáte pro každého zákazníka různé pracovní prostory.
  • Pro větší oddělení nebo pro konkrétní testy pro různé zákazníky můžete chtít mít víceklientské architektury v dřívějších fázích vývoje nebo testování. V takovém případě zvažte, že u víceklientské architektury se počet požadovaných pracovních prostorů výrazně zvyšuje.

Shrnutí

Tento článek shrnuje hlavní možnosti CI/CD pro tým, který chce vytvořit automatizovaný proces CI/CD v Prostředcích infrastruktury. I když nastíníme čtyři možnosti, omezení v reálném životě a architektura řešení se můžou použít pro hybridní možnosti nebo úplně jiné. Tento článek vám pomůže s různými možnostmi a jejich sestavením, ale nejste nuceni zvolit jenom jednu z těchto možností.

Některé scénáře nebo konkrétní položky můžou mít určitá omezení , která vám můžou bránit v přijetí některého z těchto scénářů.

Totéž platí pro nástroje. I když zde uvádíme různé nástroje, můžete zvolit jiné nástroje, které můžou poskytovat stejnou úroveň funkčnosti. Vezměte v úvahu, že Prostředky infrastruktury mají lepší integraci s některými nástroji, takže volba jiných má za následek větší omezení, která vyžadují různá alternativní řešení.

Související obsah