Co je to izolované prostředí?
Izolované vývojové prostředí znamená, že každý vývojář má svůj vlastní, izolovaný kód, na kterém pracuje. To také vyžaduje samostatnou databázi (různé aplikace mohou mít různé databázové schéma) a pokud možno izolovaný operační systém a všechny ostatní potřebné komponenty. Detaily závisí na konkrétních potřebách a dostupném vybavení.
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.
