Chybějící check-in

Relativně často se setkávám s názorem, že nevýhoda izolovaných vývojových prostředí Dynamics AX je v tom, že pokud jeden vývojář zapomene zahrnout nějaký objekt do správy verzí, aplikace nefunguje a nejde zkompilovat v ostatních vývojových prostředích. Asi tedy hodně lidí překvapím tvrzením, že já to naopak považuji za výhodu.

Podívejme se na příklad – mějme třídu A, která používá třídu B. Pokud je ve správě verzí pouze třída A, aplikace sestavená z této verze nepůjde zkompilovat, protože odkazuje na chybějící třídu B. V původním vývojovém prostředí bude vše fungovat, protože tam třída B stále je.

Jaký je tedy rozdíl mezi sdíleným a distrubovaným prostředím?

Z pohledu správy verzí – žádný. Objekt ve verzi zkrátka chybí a daná verze nemůže být úspěšně sestavena.

V Dynamics AX rozdíl je – sdílené prostředí se chová stejně jako prostředí originálního vývojáře – tedy obsahuje verzi, která neexistuje ve správě verzí, zahrnující i třídu B. Kód tedy půjde zkompilovat (dostanete pouze chybu v Best Practice) a vše bude fungovat až do chvíle, kdy korektně sestavíte aplikaci ze správy verzí. V lepším případě to bude ten samý den v nočním buildu, v horším případě někdy později, třeba když chcete vytvořit větev ve správě verzí nebo znovu sestavit zkolabované vývojové vývojové prostředí (a zjistíte, že to nejde).

Stručně řečeno, chyby je třeba nacházet co nejdříve a sdílené prostředí tento typ chyb zakrývá. Není to žádný kritický problém a noční build to vcelku efektivně řeší, ale rozhodně bych zakrývání chyb nenazval výhodou.

K tomuto tématu jsem se setkal s ještě jedním argumentem: „My stejně vždycky kopírujeme vrstvy, nikdy nesestavujeme přímo ze správy verzí“. To zní skoro jako :„Samozřejmě že používáme správu verzí. Jen se nestaráme, jestli v ní jsou nějaké objekty.“ 🙂

Napsat komentář

Vaše emailová adresa nebude zveřejněna.