Models and moving projects to live

(1) Share

Report

Posted on by Abby Abraham

314

I am on AX2012 R3 CU8

I have simple report developed in CUS layer. I normally create a project and export/import this as xpo. from dev env into prod env.

I keep reading that the recommended way to move code modifications is via models. I can see this for ISVs.

But I don't understand this for my scenario; do we create models for every small customization? Then I would have 100s of models.

Can someone kindly explain the best practice in moving a simple report or code from dev to live env.

Thanks in advance..

*This post is locked for comments

I have the same question (0)

All responses (10)

Answers (1)

Sohaib Cheema 49,438 User Group Leader on at

Like (1)

Report

You can take it as 3 or 4 steps

1) Take latest copy of Model Store from production and import model store on DEV.

2) Do your changes on DEV

3) Do your testing on DEV or any other server(if you have such as UAT)

4) Do reversal of step #1 i.e. take Model store from a server where you will perform testing and import it on Production

Was this reply helpful? Yes No
Martin Dráb 237,880 Most Valuable Professional on at

Like (1)

Report

Importing an .xpo is an equivalent of making manual changes in production. It's very risky - nobody should want to do that!

Then you also have to recompile the whole application and generate CIL, which you wouldn't have to do in production if you followed the recommended procedure of importing an already-compiled modelstore.

It's enough to have a single model for all your customizations; creating a new model for each change would be a bad idea.

Was this reply helpful? Yes No
Abby Abraham 314 on at

Like (0)

Report

Thanks for your reply. This would work if I am the only developer.

But we have multiple developers and I cannot move my model db to live as it will override any changes that other developers may move to live from the time I imported the live model store into my Dev.

What we do now is if a developer moves code changes to live I would import his changes to my dev env using xpo for testing to make sure the code changes does not conflict with my code changes.

What am I missing?

Was this reply helpful? Yes No
Zain Bokhari 3,208 Moderator on at

Like (1)

Report

I don't see you having any other options in this case.

Was this reply helpful? Yes No
Verified answer

Vilmos Kintera 46,149 on at

Like (2)

Report

You are missing the use of a Version Control system.

Each of your developers should be using their own copy of AX AOS/Database in a Virtual Machine, where they connect to their local Team Foundation Server repository, or Visual Studio Team Services online repository to check in modifications in a Development code branch. Any changes that your other developers are doing could be synchronized into your environment as well

Then you would need a code gatekeeper, who will merge your changes from the Development TFS/VSTS branch to parent branch of Development, like Test. Code merge conflicts are resolved by the gatekeeper, bad quality code is thrown back at the developer.

Once it is verified in a Test AX AOS environment where the code is built from the Test TFS/VSTS repository that has all developers' to-be-tested code, your gatekeeper can promote that checked-in code to the Production branch.

From the Production branch, you would use a Build/Staging AX environment where code gets synchronized from the Repository, you do your axbuild compile, full CIL compile, data dictionary synchronization, then export the complete AX ModelStore.

Then finally you could apply this modelstore to Production.

Yes, this is much more complex than what you used to do before - but guess what, you have done it wrong up until now!

Please refer to the documentation as well:

technet.microsoft.com/.../hh292604.aspx

Was this reply helpful? Yes No
Abby Abraham 314 on at

Like (0)

Report

Thank you. I am going to look into TFS.

So just to confirm.

The process to move a simple SSRS report from my Dev env to Live is as follows..

Using TFS...Check in to say Test Branch, then prod branch. Do a AxBuilt, CIL and Synch. Export the complete model store and import it into Prod env.

That is at least 4 hours just to make a simple report go live.

But if this is the recommended process then I will work towards this process. Looks like my go - live process will have to be on a weekend now instead of late evenings after hours.

Was this reply helpful? Yes No
Martin Dráb 237,880 Most Valuable Professional on at

Like (0)

Report

And? You have to do almost the same steps (X++ compilation, CIL, sync), so what's the difference? Either you waste the same amount of time doing it manually, or you don't spend much time with it because you've automated it. In either case it takes the same amount of time whether you're doing it in production or in a pre-production environment.

The problem with your process is that you must spent all the time in production, preventing users from working.

Another explanation is that you "save time" by don't even compiling code after deployment, which is a great way how to cause a lot of potential problems to your clients.

Was this reply helpful? Yes No
Martin Dráb 237,880 Most Valuable Professional on at

Like (1)

Report

I don't understand why you would switch from delivering from evenings to weekends if your deployments become much faster then before. Instead of importing, compiling X++, generating CIL and so on, you'll take the modelstore you've prepared before on another environment, apply it to production and synchronize database.

And when you introduce proper version control and testing to your processes (instead of just delivering source code from dev boxes), this can also guarantee that you're delivering only code that has been checked into version control (with the help of a build server) and exactly the version of application that has been signed off for installation to production.

Was this reply helpful? Yes No
Abby Abraham 314 on at

Like (0)

Report

Yes you are right. The actual go live would be the time needed to import the prepared compiled model store to Live model store and DB synchronize.

Its been only a couple of months on AX 2012. And we have so far been developing only new reports.

We import the xpo and only compile the imported project. Do an Incremental CIL and deploy the report. Since its only new reports I guess that is why there has so far been no potential problems.

We had to import an ISV model and we imported the compiled model store as recommended. But our reports have been done via xpo.

Thanks for all your answers. I know the direction to take now.

Was this reply helpful? Yes No
Suggested answer

Vilmos Kintera 46,149 on at

Like (1)

Report

Yes, you roughly got the idea right.

To confirm, our merge process is about 30 minutes with code going out every week from the Dev branch, including the TFS synchronization in AX Build. Cutoff for any check-ins is Thursday afternoon.

Then the automated build process is started in the evening, that takes about 80 minutes to finish all of the steps (compilations, synch, modelstore export).

Once maintenance comes on Friday the modelstore is already good to go, importing it to a temporary schema can be done while the Live environment is still up, takes about 10 minutes. Then the actual outage starts, where you shut all AOSes, apply the temporary modelstore schema to be the actual live one (it is a swap), start an AX AOS in maintenance mode, do your synchronization/setup/report deployment/whatsoever as part of the release process to Live, restart the AOS and fire up the live environment again for general availability. The actual outage including a couple of business process tests rarely takes more than 60-90 minutes.

Was this reply helpful? Yes No