Správa zdrojového kódu se soubory řešení
Nástroj SolutionPackager lze použít s jakýmkoli systémem správy zdrojových kódů. Po extrahování souboru .zip s řešením do složky jednoduše soubory přidejte a odešlete do systému správy zdrojového kódu. Tyto soubory lze poté synchronizovat s jiným počítačem, kde je lze zabalit do nového identického souboru .zip s řešením.
Důležitým aspektem při použití extrahovaných souborů součástí ve správě zdrojových souborů je to, že přidání všech souborů do správy zdrojového kódu může způsobit zbytečnou duplicitu. Viz Referenční informace k souboru součásti řešení, kde vidíte, které soubory jsou generovány pro každý typ součásti a které soubory jsou doporučeny pro použití ve správě zdrojového kódu.
Protože jsou pro řešení nezbytná další vlastní nastavení a změny, měli by vývojáři upravit nebo přizpůsobit součásti pomocí existujících prostředků, opětovným exportem vytvořit soubor .zip a extrahovat komprimovaný soubor řešení do stejné složky.
Důležité
S výjimkou oddílů popsaných v části Kdy upravovat soubor s vlastními nastaveními není podporována ruční úprava extrahovaných souborů se součástmi a souborů .zip.
Když nástroj SolutionPackager extrahuje soubory součástí, nepřepíše existující soubory spučástí se stejným názvem, pokud je jejich obsah identický. Kromě toho nástroj ctí atribut jen pro čtení u souborů součástí, čímž v okně konzoly vytvoří varování, že konkrétní soubory nebyly zapsány. To umožňuje uživateli ve správě zdrojového kódu rezervovat minimální sadu souborů, které se změní. Parametr /clobber
lze použít k přepsání a způsobit zapsání nebo odstranění souborů jen pro čtení. Parametr /allowWrite
lze použít k posouzení toho, jaký dopad má operace extrakce, aniž by skutečně zapisovala nebo mazala soubory. Použití parametru /allowWrite
s podrobným protokolováním je účinné.
Po dokončení operace extrakce s minimální sadou souborů rezervovaných ze správy zdrojového kódu může vývojář odeslat změněné soubory zpět do správy zdrojového kódu, jako je tomu u jakéhokoli jiného typu zdrojového souboru.
Týmový vývoj
Pokud na stejné součásti řešení pracuje více vývojářů, může dojít ke konfliktu, kde změny od dvou vývojářů povedou ke změnám jednoho souboru. To je minimalizováno rozkladem každé jednotlivě upravitelné součásti nebo dílčí součásti do samostatného souboru. Vemte si následující příklad.
Vývojář A i B pracují na stejném řešení.
Na nezávislých počítačích oba získají nejnovější zdroje řešení ze správy zdrojového kódu, zabalí a importují soubor .zip nespravovaného řešení do nezávislých organizací Microsoft Dataverse.
Vývojář A přizpůsobí systémové zobrazení „Aktivní kontakty“ a hlavní formulář pro entitu Kontakt.
Vývojář B přizpůsobí hlavní formulář pro entitu Obchodní vztah a změní „Zobrazení vyhledávání kontaktů“.
Oba vývojáři exportují soubor .zip nespravovaného řešení a extrahují jej.
Vývojář A bude muset rezervovat jeden soubor pro hlavní formulář Kontakt a jeden soubor pro zobrazení „Aktivní kontakty“.
Vývojář B bude muset rezervovat jeden soubor pro hlavní formulář Obchodní vztah a jeden soubor pro „Zobrazení vyhledávání kontaktů“.
Oba vývojáři mohou soubory odesílat v libovolném pořadí, jak budou měnit jednotlivé soubory.
Jakmile oba odešlou všechny soubory, mohou opakovat krok č. 2 a poté pokračovat ve změnách ve svých nezávislých organizacích. Každý z nich provádí obě sady změn, aniž by přepisovali vlastní práci.
Předchozí příklad funguje pouze v případě změn samostatných souborů. Je nevyhnutelné, že nezávislé vlastní nastavení vyžadují změny v jednom souboru. Na základě výše uvedeného příkladu vidíte, že vývojář B přizpůsobil zobrazení „Aktivní kontakty“, zatímco vývojář A jej přizpůsobil také. V tomto novém příkladu začíná být důležité pořadí událostí. Správný proces napravení této nesnáze je v plné podobě uveden následovně.
Vývojář A i B pracují na stejném řešení.
Na nezávislých počítačích oba získají nejnovější zdroje řešení ze správy zdrojového kódu, zabalí a importují soubor .zip nespravovaného řešení do nezávislých organizací .
Vývojář A přizpůsobí systémové zobrazení „Aktivní kontakty“ a hlavní formulář pro entitu Kontakt.
Vývojář B přizpůsobí hlavní formulář pro entitu Obchodní vztah a změní „Aktivní kontakty“.
Oba vývojáři exportují soubor . zip nespravovaného řešení a extrahují jej.
Vývojář A bude muset rezervovat jeden soubor pro hlavní formulář Kontakt a jeden soubor pro zobrazení „Aktivní kontakty“.
Vývojář B bude muset rezervovat jeden soubor pro hlavní formulář Obchodní vztah a jeden soubor pro zobrazení „Aktivní kontakty“.
Vývojář A je připraven jako první.
Před odesláním změn do správy zdrojového kódu si vývojář A musí nejprve stáhnout nejnovější zdroje, aby zkontroloval, zda nedošlo ke konfliktu změn s předchozími vrácenými změnami.
Neexistují žádné konflikty, takže může vývojář A soubory odeslat.
Vývojář B je připraven jako další a následuje vývojáře A.
Před odesláním změn si musí si vývojář B nejprve stáhnout nejnovější zdroje, aby zkontroloval, zda nedošlo ke konfliktu jeho změn s předchozími vrácenými změnami.
Dochází ke konfliktu, protože soubor pro „Aktivní kontakty“ byl od posledního načtení nejnovějších zdrojů vývojářem B změněn.
Vývojář B musí konflikt napravit. Je možné, že funkce používaného systému správy zdrojového kódu může tomuto procesu pomoci. Jinak lze použít následující možnosti.
Vývojář B prostřednictvím historie správy zdrojového kódu, pokud je k dispozici, může vidět, že vývojář A provedl předchozí změnu. Prostřednictvím přímé komunikace mohou diskutovat o každé změně. Poté musí vývojář B pouze aktualizovat organizaci dohodnutým řešením. Vývojář B poté exportuje, extrahuje a přepíše konfliktní soubor a odešle.
Povolte, aby správa zdrojového kódu mohla přepsat místní soubor. Vývojář B sbalí řešení a importuje jej do své organizace, poté vyhodnotí stav zobrazení a podle potřeby jej znovu přizpůsobí. Dále vývojář B může exportovat, extrahovat a přepsat konfliktní soubor.
Pokud lze předchozí změnu považovat za zbytnou, vývojář B umožní své kopii souboru přepsat verzi ve správě zdrojového kódu a odešle ji.
Ať už pracujete ve sdílené nebo nezávislé organizaci, týmový vývoj řešení Dataverse vyžaduje, aby si lidé aktivně pracující na společném řešení byli vědomi práce ostatních. Nástroj SolutionPackager tuto potřebu zcela neodstraní, ale umožňuje snadné sloučení nekonfliktních změn na úrovni správy zdrojového kódu a aktivně zvýrazňuje stručně zobrazené součásti, ve kterých došlo ke konfliktům.
Následující oddíly obsahují obecné procesy pro efektivní použití nástroje SolutionPackager ve správě zdrojového kódu při týmovém vývoji. Tyto procesy fungují stejně s nezávislými organizacemi jako se sdílenými vývojářskými organizacemi, ačkoli se sdílenými organizacemi bude export a extrakce přirozeně zahrnovat všechny změny přítomné v řešení, nejen ty, které provedl vývojář provádějící export. Podobně při importu souboru .zip s řešením dojde k přirozenému chování, které přepíše všechny součásti.
Vytvoření řešení
Následující postup obsahuje typické kroky použité při prvním vytváření řešení.
V čisté organizaci vytvořte řešení na serveru Dataverse a poté podle potřeby přidejte nebo vytvořte součásti.
Až budete připraveni přihlásit změny, proveďte následující.
Exportujte nespravované řešení.
Pomocí nástroje SolutionPackager rozbalte řešení do souborů se součástmi.
Z těchto extrahovaných souborů součástí přidejte potřebné soubory do správy zdrojového kódu.
Odešlete tyto změny do správy zdrojového kódu.
Změna řešení
Následující postup obsahuje typické kroky použité při změně stávajícího řešení.
Synchronizujte nebo stáhněte nejnovější zdroje souborů součásti řešení.
Pomocí nástroje SolutionPackager zabalte soubory součásti do souboru .zip nespravovaného řešení.
Importujte soubor nespravovaného řešení do organizace.
Přizpůsobte a upravte řešení podle potřeby.
Až budete připraveni vrátit změněné soubory do správy zdrojového kódu, proveďte následující.
Exportujte nespravované řešení.
Pomocí nástroje SolutionPackager rozbalte exportované řešení do souborů součásti.
Synchronizujte nebo získejte nejnovější zdroje ze správy zdrojového kódu.
Napravte jakékoli existující konflikty.
Odešlete změny do správy zdrojového kódu.
Kroky 2 a 3 musí být provedeny dříve, než dojde k dalším úpravám v organizaci pro vývoj. V kroku 5 musí být krok b dokončen před krokem c.
Viz také
Reference souboru komponent řešení (SolutionPackager)
Nástroj SolutionPackager