Axapta, nyní Dynamics AX, se během času podstatně vyvinula. Začínala jako dvouvrstvá aplikace, pak přidala aplikační server, webový portál, .NET Interop, SSRS a spoustu dalších věcí. Nyní nabízí mnohem více funkcí, lépe škáluje, může snadno spolupracovat s externími systémy apod.

Pro implementátory a vývojáře modulů tato složitost a velikost projektů vyžaduje (mimo spousty jiných věcí) odpovídající vývojové postupy. Používání izolovaných vývojových prostředí je jedna z těchto věcí – pokud více vývojářů pracuje na stejném prostředí, mohou se navzájem blokovat, nemohou věřit žádným testům protože kód i data se mohou kdykoli změnit, a tak dále.

Naneštěstí je většina AX týmů zvyklá na model sdílených prostředí a nechce ho měnit, navzdory všem očividným a často se projevujícím problémům. Chybí snaha předcházet problémům i znalosti fugování správy verzí a souvisejících procesů.

Je také pravda, že Microsoft neprojevil moc snahy pomoci partnerům se této změně přizpůsobit.

Teď máme AX2012 a ačkoli je v ní používání sdílených prostředí ještě obtížnější, řada AX týmů raději plýtvá energií na upravování AX tak, aby podporovala sdílená prostředí, místo aby změnily svůj vlastní přístup.

Některé společnosti také zkouší používat sdílená prostředí s Team Foundation Serverem. Tento scénář není podporován – můžete ho použít, pokud opravdu chcete, ale musíte se připravit na řešení určitých potíží. Firmy je bohužel vetšinou ignorují dokud se s nimi nepotkají naživo.

Vytvořit proces a zvyknout si na izolovaná vývojová prostředí také stojí čas a energii – ale řeší to mnoho problémů a přináší nové možnosti.

Pro jednoho klienta s AX2012 RTM a Team Foundation Serverem 2010 jsem sepsal stručné shrnutí rozdílů mezi sdíleným a izolovaným prostředím – viz tabulky níže. Ačkoli je to hodně zaměřené na tuto konkrétní konfiguraci, řada bodů je platná obecně.

Shrnutí bere některé informace z dokumentu Developing Solutions in a Shared AOS Development Environment od Microsoftu – nepřehlédněte ho, obsahuje dodatečné detaily a doporučení.

Izolace a paralelismus

	Sdílené prostředí	Izolované prostředí
Paralelní vývoj	Nelze – existuje jen jeden kód	Vyvojáři mohou paralelně pracovat na stejných objektech
Izolovaný vývoj	Žádná izolace – jeden vývojář může zablokovat všechny ostatní	Plná izolace – změny v kódu nemají vliv na ostatní vývojáře
Izolace systému	Žádná izolace – lze mít pouze jednu konfiguraci AOS, OS, IIS…	Každý vývojář může používat odlišnou konfiguraci
Izolace dat	Žádná izolace – databáze je sdílená	Data jsou izolována – žádné neočekávané změny v datech. Sdílení dat je komplikované.
Izolace sad změn	Změnové sady nejsou izolovány. To vede k provázáným modifikacím které nemohou být snadno použity samostatně.	Sady změn jsou izolovány a vždy je jasná jejich sekvence
Nejnovější verze	Vždy obsahuje nejnovější verzi	Vyvojáři musí získat nejnovější verzi  ze serveru
Operace	Souběžné operrace jako kompilace nebo generování CIL nejsou podporovány	Žádné konflikty
Debugování IL	Breakpoint v CIL bežícím na AOS zablokuje toto AOS – je třeba samostatné AOS (nebo i více než jedno)	AOS není používáno nikým jíným = žádný problém

Větvení a slučování

	Sdílené prostředí	Izolované prostředí
Větvení	Nelze Alternativní řešení: Samostatné sdílení prostředí pro každou větev	Různí vývojáři mohou pracovat na různých větvích. Přepínání mezi větvemi (a synchronizace databáze) může vést ke ztrátě dat. Pokud je to problém, řešením může být samostatná databáze pro každou větev.
Řešení konfliktů	Žádný souběžný vývoj = žádné konflikty	V případě paralelního vývoje je slučování nevyhnutelné

TFS Workspace

	Sdílené prostředí	Izolované prostředí
Typ  workspace	Sdílené workspace (několik omezení, například je možné změnit objekt editovaný někým jiným) Soukromá workspace – vyžaduje modifikaci	Soukromá workspace

Správa

	Sdílené prostředí	Izolované prostředí
Správa OS	Jeden stroj	Více strojů – vyžaduje více zdrojů; komplexnější architektura
Správa databáze	Jeden stroj	Více databází – větší spotřeba místa
Dopad restartu AOS	Ovlivněni jsou všichni vývojáři	Ovlivněn je jediný vývojář
Dopad výpadku sítě	Typicky zablokuje celý vývoj	Pokud se používají lokální prostředí, vývoj může pokračovat.
Licence	Jsou třeba licence na Terminal Server	Je třeba více licencí, např. pro OS

Výkon

	Sdílené prostředí	Izolované prostředí
Izolace	Žádná izolace – zátěž způsobená jedním vývojářem ovlivňuje i ostatní	Logická izolace; prakticky to záleží na konfiguraci (více vývojářů na stejném HW se může setkávat s obdobnými problémy jako ve sdíleném prostředí)

Obecně řečeno, izolovaná prostředí jsou nedocenitelná pokud více vývojářů pracuje na kódu stejné aplikace, což je dnes spíše pravidlo než výjimka, zvláště na ISV projektech a větších implementacích. Nemusí se to vyplatit na skutečně malých implementacích nebo pokud poskytujete spíše opravy než regulerní vývoj softwaru.