Proper code deploy procedure

(0) Share

Report

Posted on by akrimmer

135

I have been tasked with the 2nd attempt at deploying AX for my current employer. The 1st attempt was with AX 2012 and ended in a complete teardown before going live.

This new install is a fresh server build and install of AX 2012 R2 with three environments: PROD, LAB and DEV. We are not yet live but users started their initial set up work in PROD. We then rolled the complete DBs from PROD to LAB and DEV. Users have been working in LAB, training and entering test transactions. All custom code work is being done in DEV. We are now ready to deploy some of the DEV code to LAB.

Initially, we did a complete modelstore export from DEV and import into LAB. Which was successful. However, custom security roles had been defined in LAB which are part of hte USR layer. When we rolled from DEV to LAB, those changes were lost. So we restored the LAB DBs from prior to the roll and are rethinking the process.

We want to follow the recommended process of exporting/importing the modelstore file when moving changes from DEV to LAB and LAB to PROD, but we cannot lose any customizations that may be in the USR layer in any of the higher environments.

Our proposed solution is that when we need to deploy new code, we export the USR layer from LAB (or PROD once live), import it into DEV, run a full compile in DEV, export the modelstore from DEV, then import the modelstore to LAB and eventually from LAB to PROD.

My concern is that based on the MS whitepaper and the information on this blog post:

axwonders.blogspot.com/.../deploying-customizations-between-ax.html

We might be setting ourselves up for future problems due to possible ID conflicts by importing the single USR layer from LAB/PROD to DEV.

Will the proposed solution cause us problems?

It seems that the recommended solution from MS for our environment would be that when new code needs to be deployed, we should start with a fresh DB in DEV, export the complete modelstore from PROD to DEV. Make our customizations in DEV and then export the complete modelstore from DEV to LAB and then LAB to PROD. But that would still leave us with the possibility of losing any customizations done to LAB or PROD while the work was being done in DEV, correct?

I appreciate any help anyone can provide. I am still trying to wrap my head around AX. :)

*This post is locked for comments

I have the same question (0)

All responses (10)

Answers (1)

dolee 11,279 on at

Like (0)

Report

Hi there,

Here's my 2 cents:

I think the easy way out is:

- When deploy from DEV to LAB, use XPO files.

- LAB would act as the testing environment for all modifications.

- Add a 4th environment (PRE-PROD). When you want to deploy things to PROD, initialize PRE-PROD with PROD and deploy the changes from LAB to PRE-PROD (using model files) first.

- Do some final testing in PRE-PROD and deploy to PROD when ready.

- finally, re-initialize DEV and LAB with PROD.

The PRE-PROD environment should take care of the ID-conflict concern.

On the other hand, if you want to follow Microsoft's best practice, you will need 2 more environments (TEST and PRE-PROD). LAB is technically a development environment and you'll need a separate TEST environment. Then you'll be able to follow the practices mentioned in this whitepaper (www.microsoft.com/.../details.aspx)

Was this reply helpful? Yes No
Søren Rasmussen - B... 817 on at

Like (0)

Report

Notice, that you will lose metadata when using XPO's and since the XPO works on full objects you will not be able to keep the ability of splitting e.g. methods on an class on to multiple models.

Was this reply helpful? Yes No
akrimmer 135 on at

Like (0)

Report

Thanks for the reply.

Based on your respose and the MS white paper, this is the new plan I hope to propose. Does this look valid:

http://i.imgur.com/qwZCCFT.jpg

Being that this is 2012 R2, the "Initialization" of each envrionment only needs to be a clean MicrosoftDynamicsAX_model database, correct? We should not need to move the MicrosoftDynamicsAX database unless we wanted PROD data to test with?

Was this reply helpful? Yes No
Søren Rasmussen - B... 817 on at

Like (0)

Report

It looks right.

As for the database you are right too. From version R2 the models have their own database allowing you to do seperate data and code baselining.

Was this reply helpful? Yes No
dolee 11,279 on at

Like (0)

Report

2 suggestions:

- In step 2, use model files instead of modelstore as the medium to transfer customization to PRE-PROD. Import of modelstore will stop if there's an elementID conflict. On the other hand, import with model files will get the element ID assignment taken care of.

- After that you'll want to prepare a modelstore for PROD in PRE-PROD, so a full compile is needed there also.

Was this reply helpful? Yes No
akrimmer 135 on at

Like (0)

Report

I guess I am confused. The MS white paper seems to suggest that anytime use use model files you run the risk of ID conflicts. But using the model store file prevents that. Your statement contradicts that. Unless I am reading the white paper wrong.

Was this reply helpful? Yes No
dolee 11,279 on at

Like (0)

Report

I am referring to information on this page (technet.microsoft.com/.../hh352326.aspx)

Element IDs are installation specific, and during model files installation, each object get their ID by the following rules:

"During import, element handles are assigned based on the following rules, in this order:

1) If an element already exists that has the same Origin value as the imported element, replace the existing element and reuse its handle.

2) If an element already exists that has the same Type, Name, and ParentHandle values as the imported element, replace the existing element and reuse its handle.

3) Assign a new installation-specific handle that uses the next free handle, or Max+1."

So, when you import model files from LAB, each object will be assigned an elementID based on PROD environment. The end result will, in turn, be consistent with the PROD environment when you later move the modelstore to PROD.

When working with model files, the things to note is NOT TO delete existing model before re-import/upgrade (i.e. When deploying model files from LAB to PRE-PROD). Instead, just import it over the existing one.

"Element IDs and element handles are assigned at installation. Therefore, if you delete a model, and you then reimport that model or import a newer version of it, IDs and handles are randomized, and data integrity can be affected.

Instead of deleting a model before you reimport or upgrade it, import the model over the existing model."

Finally, as we always should, make sure you have a backup of the PROD data/modelstore databases before deployment. Then you will be safe to try out the methodology and fine tune it as necessary.

Cheers~

Was this reply helpful? Yes No
akrimmer 135 on at

Like (0)

Report

Thanks again!

I actually spoke with an MS Engineer today who was doing a health check for us and discussed this with him as well. I can see now the reason for using the model files when going from LAB to PRE-PROD.

One thing I am still unsure of is the reinitialization of the environments. At what point, if at all, is that really needed betwen PROD and DEV/LAB? I see why to do it to PRE-PROD. So as long as PRE-PROD is always initialized from PROD before the models are moved, that would always be the point of failure if there are any ID conflicts, yes? And the reinitialization should be importing the model files from PROD to PRE-PROD over the existing model files in PRE-PROD. Not first deleting them in PRE-PROD and them importing? Could the same be done by simply rolling all three database down from PROD to PRE-PROD? I know more work, just want to know options.

I also see in the white paper that MS says that when moving models from DEV to TEST (or LAB in my case), you SHOULD delete the model files in LAB first. Wouldn't that cause possible ID issues once those model files are moved up to PRE-PROD? Or is that taken care of by the fact that we would use model files instead of the modelstore?

Sorry for all the questions but I really appreciate the help!

Was this reply helpful? Yes No
Verified answer

dolee 11,279 on at

Like (0)

Report

Hi,

1) At what point, if at all, is that really needed betwen PROD and DEV/LAB?

Ans: I think re-initialize from PROD to DEV/LAB is a best-practice thing. If we are only talking about element-ID here, then I don't think it's *really needed*.

2) the reinitialization should be importing the model files from PROD to PRE-PROD over the existing model files in PRE-PROD.

Ans: You can do the same as you would from PRE-PROD to PROD. I.E. Export/Import modelStore between these 2 environments.

3) Could the same be done by simply rolling all three database down from PROD to PRE-PROD?

Ans: Yes that should work. You will have to take care of some settings like EP site URL, SSRS server settings, etc. In fact, I think you can try roll just the AXModel database from Prod to Pre-Prod.

(I am not 100% sure in case if element ID are stored in EP / SSRS objects on SharePoint/SQL as well...but worst case is you have to redeploy everything.)

4) I also see in the white paper that MS says that when moving models from DEV to TEST (or LAB in my case), you SHOULD delete the model files in LAB first.

Ans: Yes, it would cause possible ID issues. I think the whitepaper stated somewhere that the reason behind this is to make sure the customization is "clean" in the TEST (i.e. LAB) environment for testing.

Any possible ID conflict is taken care of when you import the model files to PRE-PROD.

For example (don't worry about the exact # assigned, I just want to show how importing with model files handles the ID):

[PREPROD] TableA(ID:15), TableB(ID:16)

[TEST/LAB] TableA(ID:15), TableB(ID:16)

[DEV] TableA(ID:20), TableB(ID:21), TableC(ID:22)

a) <DEV -> TEST/LAB (Delete then import)>

[TEST/LAB]: TableA(ID:16), TableB(ID:17), TableC(ID:15)

Assume TableC was processed first during import, it is assigned ID #15. TableA and TableB now has ID #16 and #17 respectively -> Changed.

b) <TEST/LAB -> PREPROD (import over existing)>

[PREPROD]: TableA(ID:15), TableB(ID:16), TableC(ID:17)

Note that TableA and TableB retains their existing ID because they already exists. TableC is then assigned #17 (Max + 1)

Hope it make sense.

Was this reply helpful? Yes No
akrimmer 135 on at

Like (0)

Report

VERY helpful! Thank you!! This will all help me when planning our deployment strategy. Thanks again!

Was this reply helpful? Yes No

Community site session details

Proper code deploy procedure

Helpful resources

Quick Links

Responsible AI policies

Neeraj Kumar – Community Spotlight

Congratulations to the November Top 10 Community Leaders!

Leaderboard > 🔒一 Microsoft Dynamics AX (Archived)

Featured topics

Product updates

Community site session details

Proper code deploy procedure

Helpful resources

Quick Links

Responsible AI policies

Neeraj Kumar – Community Spotlight

Congratulations to the November Top 10 Community Leaders!

Subscribe to this forum!

Select categories

Leaderboard > 🔒一 Microsoft Dynamics AX (Archived)

Featured topics

Product updates