Personalized Community is here!
Quickly customize your community to find the content you seek.
Have questions on moving to the cloud? Visit the Dynamics 365 Migration Community today! Microsoft’s extensive network of Dynamics AX and Dynamics CRM experts can help.
2022 Release Wave 1 PlanDynamics 365 release plan for the 2022 release wave 1 describes all new features releasing from April 2022 through September 2022.
2022 release wave 1 plan
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Community | FastTrack Program | Finance and Operations TechTalks | Customer Engagement TechTalks | Upcoming TechTalks | All TechTalks
Is the deployable package (https://ax.help.dynamics.com/en/wiki/create-and-apply-a-deployable-package/) is the unique method of deployment between environments?
The export/import project between environments works? ( As the old ax2012 xpo way?)
Have not done it yet (hands-on) but I would say that if you have a Visual Studio on both environment, then yes, you would be able to move the code using the projects as well. The main question is that on a TEST machine, it's likely you do not have VS installed, so at that point there is no way to move the code around other than creating a package.
you can also export import projects in axpp formats between environments
Deployable packages are more intended for final deployment of package/model.
Note: Importing exporting projects(.axpp) is very pathetic now, if you will compare it will ax2012 xpo's, because of poor compare tool of AX7
XPO files were never the correct way of code deployment, and axpp files are not the correct way either. Do whatever you want during development, but when it comes to deployment, use deployable packages.
I think you've missed to present your situation in a more clear manner. As you can see, the main topic here would be if you are thinking of these code movements between a DEV/TEST scenario, or DEV/DEV, or the (not so desired one) TEST/PROD (not that on TEST you would work like this).
Edit: the word 'deployment' means of course (from a dev/admin perspective) move code to a TEST or PROD machine; however, it can be misleading to a developer and one might use this term when referring simply to the process of moving code around (between DEV instances).
Thanks for your reply.
My scenario is small modification forms adjustements or class adjustments between DEV/TEST.
The deployage package export + import take many times for n quick modifications.
I known that for a PROD environment you must use a deployable packages.
After test the export/import project work in my case.
I did not really have time to look into how to move code between environments in AX7.
But it seems to me that it would be best if you could find ONE way of moving code, no matter where you are moving it from or to, so would that not be the best?
I can understand that you may have to have a staging Environment from where you move code to Production.But should everything else not be the same method?
Or am I missing something?
Well I do respect all the best practices, such as if we talk about AX2012, we are following Models and Model Stores as recommended way.
But my point is, many aspects have went strange in AX7, which I do believe, it needs improvement. Code deployment is one of those. Always I cannot follow BEST PRACTICE.
Let’s consider an example that I am working with more than 10 projects. There can be a situation when I need to use code of one client on other client. This is my own choice to use code of other client, to save my time. This is a real time scenario.
Now if I am moving code from one environment to other, should I follow always the best practice??? I cannot. Instead, many people cannot follow best practice always.
Why, sometimes, I cannot follow best practice always??
Because, may be package that I am going to deploy overrides my existing customized objects. There is no guarantee that always my baseline objects, will be non-customized. By saying Baseline Objects, I do mean that, objects of current environment where I am deploying package.
The same I was discussing with André, few days ago. This new compare tool has made it complex. It is forcing us to do work again, where we were able to save time.
That is kind of what I mean, there are several different scenarios in which you would like to move code from one place to another.
And I am also not sure witch method for code move you should use in the different cases, but I was just saying that perhaps it would be best if we could use only one method for it.
As I see it here are the difference scenarios where you need to move code.
Did I forget anything?
In AX2012, we did that like this.
1: Simpel copy & paste.
2-4 : xpo files or models
5: Models or perhaps modelstore backup/restore.
But how do you do it in AX7?
At AX7 there are only two ways
By Projects axpp files
As per Microsoft, we partners or end users, will not have access to production system. We cannot access it using remote desktop. We cannot deploy any code by ourselves. We will send deployable packages to Microsoft and Microsoft will apply it. (This has been told to us, by Microsoft representative at a technical conference)
For other servers (Other than production) we may choose any methodology, depending upon situation.
If we have to move a ‘whole object’ or ‘multiple objects’, packages are best way.
But for cases where we need to move ‘partial object’; we have no more option other than code merge, of course we cannot use package in this case, as it may not override elements of baseline.
For updates and hotfixes, I believe Microsoft will provide updates in same way as they did in from CTP7 to CT8. As they have not provided any hotfix and CU(s), so we cannot say what they can change as process. But most likely, offline manual update will be no more there, as it was from legacy cases such as 2012R2 to R3.
During a technical conference, people were having doubts and serious concerns, when we came to know that we cannot access Production system by remote desktop. Of course, in some regions, customers are really wild, e.g. a customer may give me a call, “I need Field ABC, on this form right now, it’s very important for me”; now as per current AX7 Service model, I have to tell to customer “you have to wait until Microsoft deploys code.”
Not sure, if Microsoft changes, with arrival of On-premises version. But most likely there will be changes.
For code snippets, use code snippets in Visual Studio.
You can also copy and paste files between projects and even manipulate files on disk directly, if you're careful enough. Visual Studio is just a nice editor of these files.
I'm not sure what you mean by point 3, but it suggests that you're deploying hotfixes in some abnormal way. Fortunately it won't be possible in AX 7, you always have to do proper deployment if you push anything to production. It doesn't matter whether code has been written by Microsoft or by yourself; it must be installed correctly in both cases.
Yes code snippets in VS is a nice feature.
If you work on several projects on different environments, would they be synchronized to those environments with your profile, or do you have to copy them manually?
About point 3, no it was not meant for MS hotfixes, but more for your own fixes.
Those times when a customer needs you to fix something asap.
I know we are not supposed to do those emergency fixes, but then you know how s*** happens :-)
As far as I know, Visual Studio doesn't support snippets synchronization. On the other hand, they're just files on disk, therefore you can synchronize them by yourself. If you depend heavily on snippets, you probably should put them into version control and map them to a folder configured in Code Snippets Manager.
Business Applications communities