emeadaxsupport: AX for Retail: Customizing your Hotfix Packages for Remote Deployments

[Blog bot]

Источник: http://blogs.msdn.com/b/axsupport/ar...ployments.aspx
==============

You may have noticed throughout 2012 R3, R3 CU8, and R3 CU9 that AX hotfix packages are quite a bit larger in size than they used to be.  This is not really a problem for most non-Retail environments:  if you’re deploying a hotfix to a series of AOS’s, AX Clients and your model store, unzipping this large hotfix to a network share and running AXUpdate.exe across the network is not that painful.  If you need to deploy a hotfix to a bunch of remote stores, however, you’re looking a lot of extra work and bandwidth.

The Problem:  Why is the hotfix package so large?

Just why are the hotfix packages so large, anyway?  I just pulled down a pretty recent hotfix and it is 750 MB:



And this is a binary-only hotfix!

A quick analysis of the resulting files shows a couple main culprits:



The updates to the Retail SDK and the Retail Online Channel are 305 MB and 135 MB respectively.  What’s going on here?

First of all, keep in mind that the patch files (MSP) are cumulative changes going all the way back to the initial 2012 R3 release.  There were a lot of changes to both of these components between R3 RTM and a post-CU9 release and each hotfix has to incorporate all previous changes into the MSP file.

Furthermore, if you look at the file structure of the Retail SDK, you’ll see that we have separate branches for R3, CU8, and now CU9.  There is a lot of duplication of files between all three of those branches and really, just a lot of files in general.  If you closely examine the contents of all of the folders you’ll see a number pictures and other binary files; even compressed these are going to take up a lot of space.

The Workaround:  Build a pared-down hotfix installer package

A tip before we get started:  if you’ve deployed a hotfix on a demo machine recently and just select all components, you’ll notice that it seems to take forever to complete.  This again is the Retail SDK:  xcopy’ing all of those files simply takes a long time to complete.  Unless you really need an updated SDK on that machine, make sure to uncheck that component in the installer.

The workaround is a similar strategy:  since we really only need the Retail SDK to be installed on developer machines** and the Online Channel is obviously only applicable on servers that will be using it, we can remove those components from the hotfix altogether.

This is just as easy as it sounds.  You can go through each subfolder in the MSI folder and delete any .MSP file that you know will not be needed on the remote machine.  If you remove the .MSP, you remove the component from the update list:



Once you have the .MSP files pared out to only the components you know your target machine needs, simply create a ZIP or RAR file that you can easily disperse to your various environments.  The resulting ZIP file for me in this scenario was only 63 MB.

** In reality you don’t even need developers to install the Retail SDK on their machines.  It would be a lot better to install it on one central machine and then manage that copy as a baseline for your source code repository system like TFS.  This will also make it much easier for you to manage code merges.

Notes:

• If you use this strategy for deploying hotfixes you need to be very sure about what components you are pulling out of the hotfix.  There may be dependencies between the components that aren’t immediately apparent.
• Keep in mind that after running the AX Update Installer there may also be follow-up steps needed.  For example, for EPOS you may need to update the channel database and deploy customized DLLs.
• For more automated options for your Retail deployments, please see options like Self-Service Retail Deployment and System Center Configuration Manager for AX Retail.

We are looking into possible solutions to this “large hotfix” problem, especially around the Retail SDK.  In the meantime use this method if it makes sense for your deployment.




Источник: http://blogs.msdn.com/b/axsupport/ar...ployments.aspx