Uspořádání řešení

Než začnete vytvářet řešení, chvíli si naplánujte strategii prostředí a strategii řešení. Zvažte následující aspekty:

Aspekt	Zvážení
Obor aplikace	Zahrnuje vaše implementace více aplikací, jako je Prodej, Customer Service, Field Service, Finance atd.?
Interval vydávání	Jak často plánujete nasadit aktualizace do produkčního prostředí? Je vaše metodologie doručování založená na agilních postupech, jako jsou cykly sprintů?
Podpora produkčního prostředí	Jak řešíte naléhavé opravy v produkčním prostředí, aniž byste předčasně zavedli nové funkce?
Architektura řešení	Kolik řešení spravujete? Sdílejí tato řešení komponenty nebo závisí na sobě?
Plánování prostředí	Kolik prostředí Microsoft Dataverse potřebujete k podpoře životního cyklu vývoje? Potřebujete samostatná prostředí pro vývoj, testování a produkci? Pracují vývojáři ve sdíleném prostředí společně nebo vyžadují, aby izolovaná prostředí fungovala nezávisle?

Následující části popisují tři strategie uspořádané od nejjednodušších po nejsložitější a zvýrazňují jejich příslušné výhody a nevýhody.

Strategie jednoho řešení

Všechna vlastní nastavení se během vývoje seskupí do jednoho nespravovaného řešení, které se později vyexportuje jako jedno spravované řešení pro nasazení.

Doporučeno pro:

• Implementace v malém měřítku
• Scénáře, kdy budoucí modularizace není pravděpodobné

Výhoda	Nevýhoda
Zjednodušené nastavení a správa prostředí	V případě potřeby vyžaduje větší úsilí při škálování nebo modularizaci.
Zjednodušené nasazení S jediným řešením pro správu je export a import napříč prostředími jednoduchý a méně náchylný k chybám.	Jedno řešení obsahující velký počet přizpůsobení může způsobit delší dobu nasazení. Pokud chcete zmenšit velikost řešení, použijte segmentaci tabulky. Pokud chcete zkrátit dobu importu, přejděte na doporučení k výkonu.
Snadnější vyhledání, auditování a správa změn.	Když ve stejném vývojovém prostředí pracuje více vývojářů, riskují přepsání změn mezi sebou. Toto riziko je možné snížit implementací správy verzí zdrojového kódu, přijetím strategie větvení a použitím vyhrazeného vývojového prostředí pro každou větev. Strategie správy verzí zdrojového kódu a větvení poskytují mechanismy sledování změn, podpory spolupráce a řešení konfliktů. Další informace: Přijměte strategii větvení v Gitu

Poznámka

Nedávná vylepšení platformy Microsoft Power Platform zkrátila dobu importu spravovaných řešení, včetně těch, které používají možnost upgradu. Mezi tyto optimalizace patří lepší zpracování závislostí součástí a snížení režie u nezměněných komponent. Informace o tom, jak tato vylepšení využívat, najdete v doporučeních k výkonu.

Několik řešení ve stejném vývojovém prostředí

V rámci jednoho vývojového prostředí se udržuje několik nespravovaných řešení, která jsou obvykle vyhrazená pro nesouvisející funkce nebo moduly.

Doporučeno pro:

• Implementace v malém měřítku s odlišnými a nezávislými funkčními oblastmi, které nesdílely komponenty.

Výhoda	Nevýhoda
Zjednodušené nastavení a správa prostředí	Udržování více nespravovaných řešení ve stejném vývojovém prostředí zvyšuje pravděpodobnost konfliktů závislostí. Můžete například narazit na situaci, kdy řešení A nejde importovat, protože závisí na řešení B, zatímco řešení B se nedá importovat, protože závisí na řešení A.
Funkční oblasti je možné nasazovat nezávisle na sobě.	Několik vývojářů pracujících na stejném vývojovém prostředí může přepsat změny ostatních. Práce v nespravovaném řešení neposkytuje izolaci. Každá úprava se použije přímo v prostředí bez ohledu na to, které řešení se upravuje.

Poznámka

Pokud máte ve stejném vývojovém prostředí několik řešení, často vytváříte vrstvy po importu spravovaných řešení do cílového prostředí. Další informace: Vrstvy řešení a chování při slučování

Je důležité, abyste:

• Nezahrnujte stejnou nespravovanou komponentu do více než jednoho řešení.
• Máte jenom jedno řešení, které zahrnuje všechny tabulky. Nemějte dvě různá řešení, která obě obsahují tabulky. Důvodem je, že často existuje riziko jednoho vztahu mezi tabulkami, který vytváří závislost mezi řešeními a v pozdějším okamžiku může způsobovat problémy při upgradu nebo odstraňování řešení v cílovém prostředí.
• Použijte pouze jednoho vydavatele řešení. Vydavatel řešení vlastní komponenty spravovaného řešení a jeho přidružení není možné později změnit. Pokud se například vlastní tabulka importuje jako spravovaná prostřednictvím řešení A s Publisherem X, nemůžete ji později přesunout do řešení B s Publisherem Y. Jedinou možností je odstranit tabulku, upgradovat řešení A, aby se tabulka odebrala z cílového systému, a pak znovu vytvořit tabulku v řešení B s Publisherem Y a importovat řešení B. Výsledkem tohoto procesu je ztráta všech dat uložených ve vlastní tabulce, pokud není předem migrována.
• Vyhněte se vytváření závislostí mezi řešeními. Závislosti vynucují pořadí importu a mohou způsobovat problémy. Pokud máte například jedno řešení pro tabulky a jiné pro cloudové procesy a tok se opírá o vlastní sloupec, funguje během vývoje, protože sloupec existuje. Pokud se ale do cílového prostředí naimportuje jenom řešení cloudového toku, proces importu nemusí rozpoznat závislost na vlastním sloupci. V důsledku toho se řešení toku úspěšně nainstaluje, ale samotný tok nefunguje. Další informace: Příklady závislostí vytvořených několika řešeními

Příklady závislostí vytvořených několika řešeními

• Pásy karet aplikace. Když panel nástrojů aplikace nebo mapu stránek stejné aplikace upraví více řešení.
• Pluginy nebo cloudové toky Pokud modul plug-in nebo tok aktivuje vlastní sloupec nebo aktualizuje vlastní tabulku, objekt závisí na těchto vlastních tabulkách.
• Role zabezpečení. Pokud existují vlastní tabulky, role zabezpečení obvykle závisí na těchto tabulkách pro uživatelský přístup.

Několik řešení s vyhrazenými vývojovými prostředími

Tato strategie zahrnuje vývoj jednotlivých nespravovaných řešení ve vlastním izolovaném vývojovém prostředí Dataverse. Tato strategie se běžně používá v modulárních architekturách, kde se například sestavují a spravují nezávisle různé aplikace, jako jsou Prodej, Služby zákazníkům nebo Field Service. Základní řešení obsahující běžné komponenty (například tabulky účtů a kontaktů) se vytvoří a nasadí jako spravované řešení do každého vývojového prostředí specifického pro aplikace. Každá aplikace pak má vlastní nespravované řešení, které je vrstvené nad základním spravovaným řešením, což týmům umožňuje rozšířit funkce beze změny základního základu.

Doporučeno pro:

• Rozsáhlé podnikové projekty.
• Týmy s více vývojáři nebo partnery
• Scénáře vyžadující přísné zásady správného řízení a kanály CI/CD

Výhoda	Nevýhoda
Snadnější růst a vývoj systému přidáním nebo aktualizací modulů, aniž by to mělo vliv na ostatní.	Vyšší režijní náklady na infrastrukturu a údržbu
Několik týmů může paralelně pracovat na různých modulech bez konfliktu se změnami mezi sebou.	Vyžaduje robustní strategii prostředí a zásady správného řízení.
Snadnější implementace automatizovaných testovacích postupů a postupů DevOps	Složitější nasazení
Menší řešení se rychleji nasazují, zejména v kanálech CI/CD, pokud potřebujete nasadit jenom konkrétní aplikaci.
Chyby nebo regrese se snadněji trasují, když jsou změny izolované pro konkrétní moduly.

Jak vytvořit vrstvení řešení

Poznámka

Před vytvořením řešení v následujících krocích použijte stejného vydavatele pro všechna vaše řešení v různých prostředích. Další informace: Vydavatel řešení

1. Ve vývojovém prostředí base máte základní řešení s běžnými nespravovanými tabulkami a žádnými dalšími tabulkami. Pak toto řešení vyexportujte jako spravované.
2. Pro vrstvu rozšíření nebo aplikace nastavíte druhé vývojové prostředí, které se později bude nacházet nad základní vrstvou.
3. Spravovanou základní vrstvu importujete do prostředí pro vývoj aplikační vrstvy a vytvoříte nespravované řešení pro tuto vrstvu.
4. Teď můžete datový model rozšířit přidáním dalších tabulek, sloupců, relací mezi tabulkami, modulů plug-in, toků atd. do konkrétního řešení "aplikace". Poté exportujte řešení aplikace jako spravované. Všimněte si, že řešení aplikace stále závisí na základním řešení vrstvy, ale správa více řešení tímto způsobem představuje lepší přístup. Zvažte dříve zmíněný příklad toku, který závisí na vlastním sloupci. Ve většině případů se vlastní sloupec i tok nacházejí ve stejném řešení aplikace. I když je vlastní sloupec součástí základního řešení, musíte toto základní řešení nejprve dokončit a nasadit jako spravované, jinak nelze vytvořit žádný tok uvnitř aplikačního řešení.
5. Ve svém provozním prostředí importujte spravovanou základní vrstvu a poté importujte spravovanou aplikační vrstvu. Tím se v prostředí vytvoří dvě spravované vrstvy s jasnými závislostmi mezi spravovanými řešeními.
6. Tento model opakujte, abyste měli tolik různých řešení, kolik potřebujete udržovat. Nicméně doporučujeme udržovat co nejmenší počet řešení, aby byla práce s vrstvami řešení dobře zvládnutelná.

Související články

Použití segmentace tabulky
Scénář 5: Podpora vývojového týmu