This is not my original blog, but i have found very good comment from Tommy Skaue on community related code deployment and i really like to make it part of my blog so all should be aware of the best practices. This is about the modelstore installation to different environment and practices we need to following during code deployments.
1. Production
Always move changes to production from a Staging/Test/User Acceptance Testing environment. Move the entire ModelStore, precompiled X++ and CIL without any errors. Install it first to a temporary database schema (http://yetanotherdynamicsaxblog.blogspot.no/2013/02/deploy-modelstore-with-less-downtime.html), then take all the PROD AOSes down, then apply it, then start 1 AOS and run a data dictionary synchronize Then start any other AOSes pointing at PROD.
2. User Acceptance Test (UAT)
Given a single test environment, you will install changes to this environment using models. There are scenarios where XPO is ok, which I will comment down below.
Given a separate build environment for test, you will move code to UAT using modelstore from build to UAT. In a perfect world, you will never install a model in UAT that has compile errors or dependency issues. Remember that whenever you install a model and need to run compile + synchronize this process will take hours. Schedule it outside testing hours or consider setup a build environment.
Code is moved from here to Production using modelstore. Data is updated from Production to UAT. Environment IDs are shared, except from any new IDs introduced in UAT waiting to be shipped to Production. 
3. Development
Some customers will accept having a customer specific developer environment, which allows us to develop customer specific customization without interfering with test. This is highly recommended. Here you will install updated models, your own and third party models, update customer specific models, merge code and compile. You can move code into this environtment using both models and XPO.
You may schedule a restaging of the data and the code in Development, meaning you backup the UAT database(s) and restore them over Development. Remember to backup the models in Development (http://yetanotherdynamicsaxblog.blogspot.no/2012/09/using-powershell-to-backup-your-ax-2012.html), in case someone forgot they had super important code in Development that wasn’t already shipped to UAT.
Over time the IDs in Development will stray away from Prod and UAT, so never move a modelstore from Development upwards without knowing what you are doing.
Models vs XPO
There are scenarios where XPO is an easy and convenient way to move code from A to B.
One clue is to know when introducing changes causes new IDs to be created. At this point, you need to know if this newly created ID will cause your UAT/Test and Prod to have different ID for the same element. If that happens, you’ve lost control and you need to restate UAT/Test again completely from Prod.
Another clue is when your XPO contains an element that contains changes bound to multiple AX models. Remember the XPO does not contain information of what change is bound to what model, so whatever you import using XPO will bind that change to the model you are currently working in. This may cause changes to be bound to a wrong model cause all sorts of havoc and issues later down the road.
So actually, you can move small changes to existing methods using XPO without introducing IDs if those changes all reside in the same model you exported the XPO from, if you catch my drift. You can also move SSRS reports with XPO safely. There are many scenarios supporting the use of XPOs, but you need to leave the mindset from pre-AX2012 where anything could be moved using XPO. Either you figure out when XPO can safely be used, or you refrain from using it altogether (like Joris recommends, sort of). 
Final note
Moving a precompiled modelstore is only good when the source and targets share the same environment IDs. Production and UAT/Test should use the same IDs, allowing you to have things properly tested before putting it in production, PLUS allowing you to prepare a precompiled ready to launch modelstore having perfectly valid element IDs.
When installing models you need to compile + synchronize. This is a time consuming process and more often you need to keep users out during.
When moving changes using XPO, you need to know how and why it will be ok to move changes using XPO. If you don’t know the how and why, then don’t use XPOs at all.
Thanks Guys
Happy Daxing
Of course, that you get XML format doesn’t mean that you get the structure you want. You still may need to transform it to something more suitable for your purposes.