Hi There!
I hope everyone is having a good week. In this post I would like to do a spotlight of Dynamics AX Musings on deploying out code in AX 2012.
Joris brings to our attention the importance of focusing on models instead of XPO's when we want to move code to different instances of AX. In addition, he does a good job explaining the issues that we will experience when using XPO to migrate code instead of using models, and in what form code should really be handled in AX 201 when it comes to deployment.
Joris also points out ways to avoid downtime in a production environment by giving examples from his own experience and by doing an analysis of the white paper Deploying Customizations Across Microsoft Dynamics AX 2012 Environments.
"I made this statement to one of our clients a few months ago, and I'd like to share it with you: moving XPOs is barbaric. Yes, barbaric. As AX developers, administrators, implementers and customers we need to move on.
Yes, moving XPOs has some benefits, but they are all benefits to circumvent proper procedure. The benefit of moving one piece of code? That's introducing risk and circumventing proper code release management (branching and merging for the version control aficionados).
The benefit of no downtime? That is bad practice, what about users that have cached versions of your code running in their sessions? Not to mention data dictionary changes. The benefit of not having to recompile the whole code base? Talk about bad practice again, and all the possible issues that come out of that. Sure, you say, but I am smart and I know what I can move without risk"
You can access this post from here.
That's all for now folks!
I agree in principle but how t manage the common situaton where the development enviornment is being worked in by several different developers who are at different stages of development. You don't want to move a whole layer of part tested code to move just one piece that is completed and ready for testing?
ReplyDeleteHi,
DeleteYes, this is an interesting question. In my opinion the best way to solve this problem would using source control. TFS, offers great flexibility in scenarios like the one you are describing.
In on hand, TFS will allow you to have multiples version of the same instance (many developers working on the same environment.
On the other hand, when deploying the code to a different environment, TFS will allow you to control the version of the code you want to introduce, let's say' to a Prod environment.
Of course, this requires planning and some sort of discipline.
I hope this helps. Are you using source control?
No we are ntoa software factory but it sounds like we might need to use it going forward!
ReplyDelete