Import a model doesn't modify the BD?

(0) Share

Report

Posted on by vanels

447

Hello!

I have two equals environments but on of them has 2 shared projects (for example) with a new code and new fields in a table.

I can export the projects as XPO and import them in the second environment, but if instead 2 projects were 50 or 100, I don't want to export one by one...

I had thought about importing and exporting the model but I see that when I import the model, its appears many errors saying that some field daoesn't exists en datatable, etc.

What is the best way to do this?

*This post is locked for comments

I have the same question (0)

All responses (13)

Answers (1)

Martin Dráb 237,882 Most Valuable Professional on at

Like (1)

Report

.xpo files indeed aren't intended for code deployment. The two options you have are deploying a model or the whole modelstore. It's all explained in Microsoft Dynamics AX 2012 White Paper: Deploying Customizations Across Microsoft Dynamics AX 2012 Environments.

You must pay attention to table and field IDs when deploying modelstore or moving AX database, but it's not the case of model deployment. Didn't you simply forget to synchronize database?

Was this reply helpful? Yes No
André Arnaud de Cal... 301,035 Super User 2025 Season 2 on at

Like (0)

Report

Hi Vanels,

In addition to the comments from Martin: Make sure that if you have multiple models, you have to move them all or in a specific order. Moving the model store will move all models at once. Probably some objects are in a wrong model. Then you have to verify if every object is existing in the correct model.

Was this reply helpful? Yes No
vanels 447 on at

Like (0)

Report

Hi,

Thanks for your answers.

Martin, I am going to read the article you say...

The table and fields ID I supose that are the same because the environments are news at the same time and with the same backup database. I want to use them as staging and test environments with a copy of data from the production environment.

I did synchronize database but with some errors...

André, I was only moving 1 model (I supose), with this sentences:

axutil export /model:"myModel" /file:modelXXX.axmodel

axutil import /file:modeloXX.axmodel /conflict:push

Is the first time I have something like that because since now we used xpo to "migrating" code and customizations :S

Thanks a lot!

Was this reply helpful? Yes No
Suggested answer

nmaenpaa 101,160 Moderator on at

Like (1)

Report

1) Make sure that you can compile the source environment succesfully, then generate full CIL and do a database sync.

2) Export modelstore from source environment

3) Import modelstore into target environment

4) Synchronize the database in the target environment. No compilation or CIL generation is needed.

Does this work for you?

Was this reply helpful? Yes No
vanels 447 on at

Like (0)

Report

Ok, I am trying now with the model (but deleting the actual before...) and after that I try this and tell you.

I'd like to see all options to decide which is the best.

We made uploads to production every week and if I work with a model and it obligate me to do an application and CIL compile... maybe it's not the best

Ok, I tell you something.

Thanks.

Was this reply helpful? Yes No
nmaenpaa 101,160 Moderator on at

Like (0)

Report

All options are described in the whitepaper that Martin mentioned above.

Was this reply helpful? Yes No
vanels 447 on at

Like (0)

Report

Hi,

I have already read the article recommended by Martin and there are things that I don't understand very well.

When it speak about deploy models on a test environment, I understand that I will have all the projects that I am developing in the development environment, but I would only like to have the ones already finished and that I want to take to production... no?

What I did with XPOs so far, even if it is not right, allowed me to update only what I wanted.

Afterwards, from test to staging it seems that the best way is to import the model, but in addition to having to compile the application, if we follow the criteria of the previous step, we would also have projects in development that I do not want that are still in staging.

Say that I currently have a development environment with all the projects and the production environment.

I have set up a new development environment where I want to take all the projects and another staging environment, so I will work with 3 environments in total ...

And after all I do not understand what is the best way because even doing tests with a project that creates a field in a table of the BD, I made the export / import of the model and compiling receipt errors...

I am lost! :|

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

Like (0)

Report

If you want different code in development and testing, you can use two branching in version control, e.g. Dev and Main. When a feature is ready for release, promote it from Dev to Main. When you want to do a release, take code from Main (while you may have work in progress in Dev).

What you completely miss is an environment for testing. You can't reasonably test in Dev, because code there isn't the same thing as what you'll deliver to production.

If you deploy something and it doesn't even compile, it either never worked or you've deployed a wrong thing. It can easily happen with XPOs, e.g. when you forget an object or it doesn't get imported correctly - that's one of reasons why you shouldn't do it.

Was this reply helpful? Yes No
vanels 447 on at

Like (0)

Report

My idea was to develop in the development environment, to pass the updates to staging so that people can test them and publish them in production.

However, if I had the 4 environments and without branches as you comment, working with models, if I understood correctly I would have the projects in development also in this environment, is that true?

Thank you for your explanations.

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

Like (0)

Report

I'm sorry, but I don't understand the sentence "I would have the projects in development also in this environment". You said you would have four environments; which of the other three is "this"? What would you deploy there?

You can call the test environment "Staging" and deploy directly from there if you want (although I prefer a separate pre-production environment independent on all test environments).

Was this reply helpful? Yes No