Vývoj AX pod kontrolou.

Bojujete v prostředí Microsoft Dynamics AX často s problémy se sdílením objektů na jednom projektu mezi více vývojáři?

Je pro vás již neúnosný čas a energie vložená do organizace sestavování a nasazování nových dávek s vývojem na cílové prostředí zákazníka?

Řešíte často přímo se zákazníkem nejasnosti nebo chyby v nasazeném vývoji?

Pokud si na některou z těchto otázek odpovíte kladně, tak pro vás mám několik tipů, vycházejících z mé osobní dlouholeté zkušenosti, jak se podobným situacím vyhnout.

Ujasněte si, jaký typ vývojového prostředí pro daný projekt potřebujete

Pro menší projekty, kde se na vývoji podílí menší počet vývojářů a kde navíc není příliš pravděpodobné, že budou potřebovat často pracovat na stejných objektech, můžete použít jedno sdílené vývojové prostředí.

Pro větší projekty použijte model distribuovaných vývojových prostředí v kombinaci s Team Foundation Serverem.

Pro velké projekty naopak použijte model distribuovaných vývojových prostředí, kdy každý vývojář má své vlastní prostředí, které si pravidelně synchronizuje z centrálního úložiště (viz. dále). Do centrálního úložiště také odevzdává svůj vývoj (většinou ve chvíli kdy má dokončenu nějakou ucelenou část).

Používejte version management

Použití správy verzí přináší množství výhod:

• Poskytuje přehled o každé změně na každém objektu a také o tom kdo a kdy změnu provedl
• Umožňuje zadat ke každé programové změně její věcný popis
• Umožňuje rychle se zorientovat v tom, co se historicky na každém objektu stalo
• Výrazně přispívá k efektivitě komunikace v týmu vývojářů pracujících na stejném projektu

Prostředí řešení Microsoft Dynamics AX nabízí několik možností jak verzovat programové změny provedené každým vývojářem.

Pro sdílený model vývojového prostředí je možné použít správu verzí, která je přímo integrovaná v AX (MorphX VCS).

V tomto případě si při započetí práce vývojář daný objekt zarezervuje a znemožní tak ostatním provádět na něm změny. To je možné až poté, kdy jsou změny na objektu vývojářem odevzdány do správy verzí, kdy se objekt odblokuje.

Pro každý projekt použijte alespoň dvě testovací prostředí. Jedno pro hlavní vývojovou větev, druhé pro hotfixy.

V případě distribuovaného modelu je potřeba si před začátkem práce obnovit všechny objekty na lokálním vývojovém prostředí z globálního úložiště verzí. Vývojáři potom mohou bez problému pracovat na stejném objektu současně. Při odevzdání práce do globálního repositáře mohou potom ale vzniknout v kódu konflikty. Většinu z těchto konfliktů ale umí použitý nástroj automaticky vyřešit. Pokud automatické vyřešení není možné, musí vývojář ošetřit v tomto okamžiku daný konflikt manuálně.

Jako globální úložiště je možné použít např. velmi dobrý nástroj Team Foundation Server (TFS) vyvinutý firmou Microsoft, který má v sobě mj. integrován ticketovací systém. Je zde potom možné zobrazit si všechny programové změny související s daným požadavkem.

Používejte nástroj pro správu nasazovaných dávek, ideálně v kombinaci s ticketovacím systémem

Nástroj pro správu dávek (dále jen RM – Release management) výrazně zvyšuje efektivitu práce při sestavení nové dávky s vývojem určeným pro nasazení na testovací nebo produkční prostředí. Mimo rychlého a bezchybného sestavení dávky přináší opět také jasný přehled o tom, kdo a kdy dávku sestavoval a jaké požadavky v ní byly obsaženy.

Přímé spojení RM s ticketovacím systémem (TS) také předchází mnoha nejasnostem a nedorozuměním v komunikaci mezi členy delivery teamu.

Na začátku je v TS jasně dáno, které požadavky mají být v dané dávce obsaženy.

Postup při sestavení může být potom následující:

• Sestavovač si zkontroluje podle čísla požadavku, že požadavek je v TS ve správném stavu a verze vývoje pro každý požadavek je odevzdána v RM (ideálně na toto má v RM podpůrnou automatickou funkcionalitu).
• Pokud je vše v pořádku, sestaví v RM novou dávku. Předtím ještě pošle e-mailem informativní ohlášku zákazníkovi a vybraným členům týmu se všemi potřebnými informacemi – zejména o nutnosti omezení provozu na cílovém prostředí v době nasazení. K sestavení dávky použije speciální BUILD prostředí.
• Ideálně má delivery team připravené PowerShell scripty, které umožní naprogramovat sekvenci kroků pro nasazení dané dávky až na cílové prostředí. Zjednodušený příklad takové sekvence může být takovýto: kompilace AOT, Full CIL kompilace, export modelstore, zastavení cílových AOS, import modelstore, synchronizace Data dictionary, opětovné spuštění cílových AOS, zaslání e-mailu zákazníkovi a ostatním zúčastněným o úspěšném nasazení nové dávky

Rozlišujte mezi sestavením dávky a nasazením dávky

Pokud není možné proces nasazení sestavené dávky plně zautomatizovat, tak nenechávejte celý proces sestavení i nasazení dávky na jedné osobě. Vzhledem k tomu, že nasazování probíhá často v nočních hodinách, tak se rozdělením rolí sníží riziko chybovosti.

Pro sestavení dávky je ideální zapojit někoho z týmu programátorů pracujících na daném projektu. Ten je schopen řešit případné nejasnosti související s odevzdaným kódem a také srozumitelně a souhrnně předat nasazovači dodatečné technické informace spojené s daným nasazení (nutnost spuštění inicializačních jobů po nasazení dávky, provedení změn v nastavení naplánovaných jobů na batch serveru, apod.).

Nasazovačem potom již nemusí být přímo vývojář, ale může to být proškolený a spolehlivý člen Operation týmu.

Používejte testovací prostředí

S procesem nasazení dávek je také spojen model použitých prostředí.
Kromě prostředí pro vývoj (DEV), pro sestavení dávky (BUILD) a cílového produkčního prostředí (PROD), je pro bezchybné odevzdání vývoje zákazníkovi nutné používat také testovací prostředí (TEST).
Ideální je mít testovací prostředí alespoň dvě. Jedno pro testování dávek předem naplánovaných v TS a druhé pro nasazování hotfixů. Druhý TEST by měl být v podstatě kopií produkčního prostředí.

Zapojte zákazníka do procesu nasazení

Abyste předešli co nejvíce nejasnostem a zbytečným konfliktům, zapojte zákazníka do procesu schvalování a testování požadavků v tiketovacím systému.

Abyste předešli co nejvíce nejasnostem a zbytečným konfliktům se zákazníkem vzniklých po nasazení dávky na produkční prostředí (ale i na testovací), je důležité nastavit proces tak, aby byl zákazník (jeho zodpovědný key-user) zapojen do procesu schvalování požadavků a testování.

V používaném TS by potom mělo být nastavením workflow zajištěno to, že dávku na PROD bude možné nasadit až v okamžiku, kdy jsou všechny související požadavky ve stavu „Otestováno a schváleno zákazníkem“.

V případě nejasností je veškerá historie ke každému požadavku přehledně dohledatelná na jednom místě.

Věřím, že Vám uvedené tipy pomohou k dosažení vyšší spokojenosti vašich zákazníků a také k vyšší efektivitě práce ve vašem týmu.

Vladislav Nový – Dynamics AX developer ve společnosti Blue Dynamic se zkušenostmi s řízením nasazování dávek vývoje.