Networg: Dataverse solutions, importy a Package Deployer

Krátké executive summary: série tří článků Networg ukazuje, že práce se solution v Dataverse není jen „export ZIPu a import do produkce“. Prakticky rozhoduje typ komponent, vrstvy, publisher, SmartDiff, volba importního režimu a u složitějších release i orchestrace přes Package Deployer. Pro běžné managed deploymenty je nejlepší default single-step upgrade přes pac solution import --stage-and-upgrade; Package Deployer má smysl až ve chvíli, kdy deployment potřebuje data, migrace, více solutions nebo vlastní logiku.

Přehled článků

Článek	Hlavní téma	Praktická hodnota
Dataverse solution component types	Platform components vs. SCF komponenty, vrstvy solution, publisher, managed properties	Pomáhá pochopit, proč se komponenty jinak diffují, importují a troubleshootují.
Making Dataverse solution imports fast	SmartDiff, single-step upgrade, Update, Stage for upgrade, benchmarky importů	Dává konkrétní doporučení, jak zrychlit CI/CD importy a čemu se vyhnout.
Package Deployer for solutions, data and migrations	Package Deployer, CMT data, runtime settings, migration hooks, Catalog	Ukazuje, kdy už PAC CLI nestačí a kdy je potřeba řízená deployment jednotka.

1. Dataverse solution component types

Originál: Dataverse solution component types

Článek vysvětluje, že Dataverse solution ZIP obsahuje více než jen seznam úprav. Důležité jsou hlavně:

solution.xml – manifest s root komponentami, type kódy, verzí, publisherem a dependencies.
customizations.xml – definice klasických platformních komponent, například tabulek, sloupců, vztahů, formulářů, views, sitemap fragmentů a ribbonů.
samostatné payload soubory – například pro pluginy, web resources a novější SCF komponenty.

Klíčové rozlišení:

Platform components jsou původní typy komponent Dataverse. Mají stabilní type codes, fixní schéma a dobře fungují se Solution Packagerem. V source controlu jsou relativně čitelné.
SCF components jsou novější framework pro typy komponent dodávané produktovými týmy Microsoftu. Type code může být runtime-assigned a lišit se mezi prostředími; import se opírá spíše o unikátní názvy než o statický type code.

Praktické dopady:

Neplést solution kontejner s vrstvou. Default Solution nebo Preferred solution nejsou izolace týmu; všechny unmanaged změny v prostředí končí ve sdílené Active layer.
Unmanaged solution má být hlavně pro vývoj a source control, ne pro deployment mimo dev prostředí.
Publisher a prefix je potřeba zvolit opatrně hned na začátku. Pozdější změna často znamená delete/recreate a u datových komponent migraci dat.
U existujících tabulek má solution obsahovat jen změněné assety, ne automaticky celou tabulku. Snižuje to vrstvy, dependencies i importní čas.
Managed komponenta nemusí být automaticky „zamčená“. Skutečné možnosti úprav určují managed properties.

Pro diagnostiku SCF typů článek uvádí endpoint:

GET ORG/api/data/v9.2/solutioncomponentdefinitions?$select=name,objecttypecode

2. Making Dataverse solution imports fast

Originál: Making Dataverse solution imports fast

Tento díl řeší, proč jsou importy managed solutions pomalé a jak je zrychlit. Hlavní doporučení: pro rutinní managed deployment používat single-step upgrade:

pac solution import --stage-and-upgrade

Technicky jde o StageAndUpgradeRequest. Výhody:

je atomický,
umí odstranit komponenty odebrané v nové verzi,
používá SmartDiff,
při chybě se rollbackne.

SmartDiff porovnává nově importovaný ZIP s předchozí verzí a zpracuje jen změněné komponenty. Neplatí ale vždy:

funguje u Update a single-step Upgrade,
nefunguje u holding importu ve dvoukrokovém Stage for upgrade,
vypne se při OverwriteUnmanagedCustomizations=true / --force-overwrite.

Benchmark z článku: solution měla 79 komponent a každá nová verze měnila jednu položku.

Scénář	Zpracováno	Server time	SmartDiff
Power Platform Pipelines install	79/79	404 s	ne
Power Platform Pipelines upgrade	28/79	120 s	ano
Maker UI Upgrade / `StageAndUpgradeAsync`	28/79	82 s	ano
Direct API Upgrade / `StageAndUpgradeAsync`	28/79	95 s	ano
Maker UI Update / `ImportSolutionAsync`	1/79 + 7 entities	15 s	ano
Maker UI Stage for upgrade + Apply	79/79 dvakrát	626 s	ne
Direct API Upgrade s `OverwriteUnmanagedCustomizations=true`	79/79	414 s	ne
Package Deployer Upgrade	28/79	93 s	ano

Praktické závěry:

--force-overwrite nepoužívat jako default. Řeší unmanaged drift silou, ale vypíná SmartDiff.
Pokud je potřeba blokovat unmanaged změny v non-dev prostředích, článek doporučuje Block unmanaged customizations.
Stage for upgrade + Apply používat jen pro migrační okno nebo dependency cleanup, ne jako běžný deployment režim.
Zbytečně nevolat „Publish all customizations“.
PAC CLI a další nástroje držet aktuální, aby používaly moderní importní endpointy.

Troubleshooting pomalých importů:

zkontrolovat msdyn_solutionhistory.msdyn_isoverwritecustomizations,
ověřit, zda neběží holding import (msdyn_suboperation=2),
hledat SmartDiffApplied v importjob XML,
použít Solution History tool for XrmToolBox,
zohlednit nedávné zapnutí nového jazyka v prostředí.

3. Package Deployer for solutions, data and migrations

Originál: Package Deployer for solutions, data and migrations

Package Deployer není „rychlejší PAC CLI“. Je to pokročilá orchestrace deploymentu, která dává smysl hlavně tehdy, když jeden import solution nestačí.

Typické důvody pro použití:

více solutions v deterministickém pořadí,
reference/config data přes Configuration Migration Tool,
runtime parametry bez rebuildu balíčku,
podmíněná logika pro různé prostředí,
datové migrace během upgrade,
custom hooky v lifecycle deploymentu.

Důležité rozdíly proti PAC CLI:

OverwriteUnmanagedCustomizations je defaultně false stejně jako u PAC CLI, takže SmartDiff zůstává zapnutý.
PublishWorkflows / aktivace pluginů a workflow je u Package Deployeru defaultně true; u PAC CLI je potřeba explicitní --activate-plugins.
Hook PreSolutionImport může přepsat importní flags pro konkrétní solution.

Package Deployer 4.0+ podle článku automaticky volí one-step nebo two-step upgrade:

pokud není skutečný kód v RunSolutionUpgradeMigrationStep, může použít one-step upgrade,
pokud existuje custom migration code, forceupgradecodestep="true" nebo je one-step vypnutý, použije two-step holding path,
RunSolutionUpgradeMigrationStep běží po holding importu a před DeleteAndPromote, tedy v migračním okně.

To je zásadní pro situace typu „přesun dat ze starého sloupce do nového“: nejdřív musí současně existovat staré i nové schéma, pak se přesunou data, a až potom se stará komponenta odstraní.

Pozor na version-skip logiku:

stejná verze → SkipSameVersion,
nižší verze → SkipLowerVersion,
vyšší verze → import,
nekompatibilní min CRM verze → skip.

Článek zdůrazňuje, že SkipSameVersion a SkipLowerVersion jsou tiché. Deployment může skončit úspěšně, i když konkrétní solution nebyla reálně importována. Proto je nutné číst Package Deployer logy, hlavně SOLUTION_STATS.

Omezení:

Package Deployer je .NET Framework / net462 a Windows-only.
Pro Linux/macOS/container CI článek zmiňuje TALXIS CLI jako workaround.
Alternativně lze balíček poslat do Power Platform Catalog, kde deployment běží platformně s frontou, retry a případným approval workflow.

Společná syntéza: co z toho plyne pro solution v Dataverse

Pro práci se solution v Dataverse je nejdůležitější oddělit tři vrstvy rozhodování:

Co je v solution: platformní komponenty, SCF komponenty, tabulky, sloupce, formuláře, flows, pluginy, data.
Jak se solution importuje: Update, single-step Upgrade, holding Stage for upgrade + Apply, Package Deployer, Catalog.
Co se děje v cílovém prostředí: managed vrstvy, Active layer, unmanaged drift, dependencies, publisher ownership, managed properties.

Praktický default pro většinu projektů:

Dev: unmanaged pro vývoj, export do source controlu.
Test/UAT/Prod: managed solution.
Běžný CI/CD import: pac solution import --stage-and-upgrade.
Bezpečnost proti driftu: blokovat unmanaged customizations místo plošného force-overwrite.
Složitější release: Package Deployer až při potřebě dat, více solutions, migrací nebo custom logiky.

Největší výkonnostní páky:

držet solution payload malý,
nepřidávat celé tabulky, pokud se mění jen jeden asset,
nepoužívat OverwriteUnmanagedCustomizations=true, pokud to není vědomé rozhodnutí,
vyhnout se dvoukrokovému Stage for upgrade, pokud není potřeba migrační okno,
kontrolovat SmartDiff a import history.

Praktický checklist pro Power Platform / Dataverse projekty

Před návrhem solution:

Zvolit publisher a prefix jako dlouhodobé rozhodnutí.
Rozdělit solutions podle ownershipu, dependencies a release cadence.
U tabulek zahrnovat jen změněné assety.
Počítat s tím, že SCF komponenty mohou mít horší diff a runtime-specific type codes.

Před deploymentem:

Používat managed solutions mimo dev prostředí.
Jako default nastavit pac solution import --stage-and-upgrade.
Nepoužívat --force-overwrite bez konkrétního důvodu.
Ověřit, zda má deployment aktivovat pluginy/workflows/flows.
Držet PAC CLI a pipeline tasky aktuální.

Při složitějším release:

Zvážit Package Deployer, pokud je potřeba více solutions, CMT data nebo runtime settings.
Pro migrace dat použít holding path a RunSolutionUpgradeMigrationStep.
Při cross-solution dependency cleanup řešit pořadí top-down / reverse order, případně změnu rozdělit do dvou releasů.
U CMT dat držet pořadí: nejdřív solutions, potom data.
OverrideDataImportSafetyChecks používat jen na čistých prostředích.

Při troubleshooting:

Kontrolovat msdyn_solutionhistory.
Ověřit msdyn_isoverwritecustomizations.
Hledat SmartDiffApplied v importjob XML.
U Package Deployeru číst SOLUTION_STATS a packagehistory.
Rozlišit „deployment doběhl“ od „každá solution byla opravdu importována“.

Rizika, limity a poznámky

Čísla benchmarku jsou z jednoho testu a jedné solution; berte je jako orientační, ne jako univerzální SLA.
SmartDiff nemusí pokrývat všechny typy platformních komponent stejně; Microsoft podporu rozšiřuje postupně.
SCF komponenty nemají jednotné statické schéma a jejich source-control diff může být méně čitelný.
Update může být rychlý, ale nemaže odebrané komponenty; pro běžné managed releasy proto není plnohodnotná náhrada upgrade.
Dvoukrokový Stage for upgrade je užitečný pro migrační okno, ale výkonově drahý.
Package Deployer přidává sílu i komplexitu. Pro jednoduchý import jednoho ZIPu je PAC CLI praktičtější.
Tiché skipy stejné nebo nižší verze v Package Deployeru jsou provozní riziko, pokud nikdo nečte logy.
Windows-only charakter Package Deployeru může komplikovat moderní Linux/container CI.