AX ontwikkeling onder controle.

Je vecht in een omgeving Microsoft Dynamics AX vaak problemen met het delen van objecten op één project tussen meerdere ontwikkelaars?

Is de tijd en energie die u steekt in het organiseren van het bouwen en inzetten van nieuwe batches met ontwikkeling naar de doelomgeving van de klant al onbetaalbaar voor u?

Lost u onduidelijkheden of fouten in de ingezette ontwikkeling vaak rechtstreeks met de klant op?

Als u op een van deze vragen ja antwoordt, heb ik enkele tips voor u, gebaseerd op mijn persoonlijke ervaring door de jaren heen, over hoe u dergelijke situaties kunt vermijden.

Verduidelijken welk type ontwikkelomgeving je nodig hebt voor het project

Voor kleinere projecten, waar minder ontwikkelaars betrokken zijn bij de ontwikkeling en waar het onwaarschijnlijk is dat ze vaak aan dezelfde objecten moeten werken, kunt u één gedeelde ontwikkelomgeving gebruiken.

Gebruik voor grotere projecten het model van de gedistribueerde ontwikkelomgeving in combinatie met Team Foundation Server.

Gebruik voor grote projecten daarentegen een gedistribueerd ontwikkelingsomgevingsmodel, waarbij elke ontwikkelaar zijn eigen omgeving heeft die hij regelmatig synchroniseert vanuit een centrale repository (zie hieronder). Zij dienen ook hun ontwikkeling in bij het centrale archief (meestal wanneer zij een volledig onderdeel hebben voltooid).

Gebruik versiebeheer

Het gebruik van versiebeheer heeft vele voordelen:

• Biedt een overzicht van elke wijziging op elk object en ook wie de wijziging heeft doorgevoerd en wanneer
• Hiermee kunt u een feitelijke beschrijving invoeren voor elke programmawijziging
• Hiermee kunt u snel uitzoeken wat er historisch gezien met elk object is gebeurd.
• Draagt aanzienlijk bij tot de doeltreffendheid van de communicatie in een team van ontwikkelaars die aan hetzelfde project werken

Milieu Microsoft Dynamics AX-oplossing biedt verschillende opties voor om de programmawijzigingen van elke ontwikkelaar in versie te brengen.

Voor een model met gedeelde ontwikkelomgeving kan versiebeheer worden gebruikt, dat rechtstreeks in AX is geïntegreerd (MorphX VCS).

In dat geval reserveert de ontwikkelaar het object bij aanvang van de werkzaamheden, zodat anderen er geen wijzigingen in kunnen aanbrengen. Dit is pas mogelijk nadat de ontwikkelaar wijzigingen aan het object heeft vastgelegd in versiebeheer, wanneer het object is gedeblokkeerd.

Gebruik ten minste twee testomgevingen voor elk project. Eén voor de hoofdontwikkelingstak, de andere voor hotfixes.

In het geval van een gedistribueerd model moet u alle objecten op de lokale ontwikkelomgeving terugzetten vanuit het globale versiedepot voordat u aan de slag gaat. Ontwikkelaars kunnen dan zonder problemen tegelijkertijd aan hetzelfde object werken. Er kunnen dan echter conflicten ontstaan in de code bij het vastleggen van het werk in het globale archief. De meeste van deze conflicten kunnen echter automatisch worden opgelost door het gebruikte instrument. Als automatische oplossing niet mogelijk is, moet de ontwikkelaar het conflict op dit punt handmatig afhandelen.

Als globaal archief kunt u bijvoorbeeld het zeer goede programma Team Foundation Server (TFS) gebruiken. ontwikkeld door Microsoft, met een geïntegreerd ticketingsysteem. Vervolgens kunnen alle programmawijzigingen met betrekking tot een bepaald verzoek worden bekeken.

Gebruik een tool voor deployment management, idealiter in combinatie met een ticketing systeem

Hulpmiddel voor vrijgavebeheer (RM) verhoogt aanzienlijk de efficiëntie van het werk bij het opzetten van een nieuwe partij met ontwikkeling bedoeld voor inzet in test- of productieomgevingen. Naast een snelle en foutloze opbouw van de batch biedt het ook een duidelijk overzicht van wie de batch wanneer heeft gebouwd en welke eisen erin zijn opgenomen.

Rechtstreekse verbinding van RM met het ticketingsysteem (TS) ook voorkomt veel verwarring en misverstanden in de communicatie tussen leden van het leveringsteam.

In het begin maakt de TS duidelijk welke eisen in een bepaalde partij moeten worden opgenomen.

De bouwprocedure kan dan als volgt verlopen:

• De bouwer controleert aan de hand van het verzoeknummer of het verzoek in de juiste staat is in TS en de ontwikkelingsversie voor elk verzoek wordt vastgelegd in RM (idealiter is er een geautomatiseerde ondersteunende functionaliteit in RM hiervoor).
• Als alles in orde is, bouwt de RM een nieuwe batch. Alvorens dit te doen, stuurt het een informatieve e-mail naar de klant en geselecteerde teamleden met alle nodige informatie - met name over de noodzaak om het verkeer op de doelomgeving te beperken tijdens de implementatie. Het zal een speciale BUILD-omgeving gebruiken om de batch te bouwen.
• Idealiter heeft het leveringsteam PowerShell-scripts gereed om een reeks stappen te programmeren om de batch naar de doelomgeving te deployen. Een vereenvoudigd voorbeeld van een dergelijke sequentie kan er als volgt uitzien: compilatie AOT, volledige CIL compilatie, export modelstore, stop doel AOS, import modelstore, synchronisatie Data dictionary, herstart doel AOS, stuur e-mail naar klant en andere belanghebbenden over succesvolle inzet van nieuwe batch.

Onderscheid maken tussen batchopstelling en batchinzet

Als het batch deployment proces niet volledig geautomatiseerd kan worden, laat dan niet het hele batch build en deployment proces over aan één persoon. Aangezien de inzet vaak 's nachts plaatsvindt, zijn de de kans op fouten wordt verkleind door de rollen te splitsen.

Om een batch te bouwen is het ideaal om iemand van het programmeerteam bij het project te betrekken. Deze persoon is in staat eventuele onduidelijkheden in verband met de ingediende code op te lossen en tevens de uitvoerder te voorzien van aanvullende technische informatie in verband met de inzet (de noodzaak om initialisatieopdrachten uit te voeren na de inzet van de batch, wijzigingen in de instellingen van geplande opdrachten op de batch-server, enz.)

De deployer hoeft dan niet direct de ontwikkelaar te zijn, maar kan een getraind en betrouwbaar lid van het Operationeel team zijn.

Gebruik een testomgeving

Het batch deployment proces is ook gekoppeld aan het model van de gebruikte omgevingen.
Naast de ontwikkelomgeving (DEV), de build batch-omgeving (BUILD) en de productiedoelomgeving (PROD) is ook een testomgeving (TEST) nodig voor de foutloze oplevering van de ontwikkeling aan de klant.
Ideaal is om ten minste twee testomgevingen te hebben. Eén voor het testen van batches die vooraf zijn gepland in TS en de andere voor het uitrollen van hotfixes. De tweede TEST moet in principe een kopie zijn van de productieomgeving.

De klant betrekken bij het implementatieproces

Betrek de klant bij het goedkeurings- en testproces van het ticketingsysteem om zoveel mogelijk verwarring en onnodige conflicten te voorkomen.

Om zoveel mogelijk verwarring en onnodige conflicten met de klant te voorkomen na het uitrollen van een batch naar een productieomgeving (maar ook naar een testomgeving), is het belangrijk het proces zo in te richten dat de klant (zijn verantwoordelijke key-user) betrokken is bij het goedkeurings- en testproces van de eisen.

De workflow instellingen in de gebruikte TS moeten er dan voor zorgen dat de batch alleen naar PROD kan worden ingezet als alle gerelateerde aanvragen in de status "Getest en goedgekeurd door klant" zijn.

In geval van verwarring is de hele geschiedenis van elk verzoek duidelijk traceerbaar op één plaats.

Ik denk dat deze tips u zullen helpen om een hogere klantentevredenheid te bereiken en ook om de efficiëntie van uw team te verhogen.

Vladislav Nový - Dynamics AX-ontwikkelaar in het bedrijf Blue Dynamic met ervaring in het beheer van ontwikkelingsbatches.