In Chapter 3, Model Management, we covered most of the tasks required for us to manage the model store, but we missed a vital process in reducing risk in the application lifecycle.
All (except the lucky) successful implementations have a deployment lifecycle process, which is closely linked to the software development process. But many fail to evolve the process, almost expecting software development to finish once the implementation is live.
Others implement a process based on the previous version of Dynamics AX, working around the issues and risks caused by this method of working. We have seen many implementations that are managed this way, highlighted when it goes wrong, costing both customer and partner time and money to correct the resulting problems such as lost code and data.
First, some quick facts on methods of transferring application code are as follows:
XPO
Imports into the layer that the client is logged into. Therefore, the code will normally be imported by the developer or their organization.
Element IDs are used if the element is found, otherwise a new Element ID is created during import. The target system is, therefore, an Element ID master.
Importing an object where a method has been deleted will not cause the method to be deleted in the target system, unless Delete elements is checked on import. In this case, all elements are deleted in the target layer and reimported (element IDs are re-used and data is preserved). If a field is removed as part of the import, the data in that field will be lost.
Model
Imports into the layer that the model was created in, and this need not be performed by the developer.
Element IDs are used if the element is found. Otherwise, a new Element ID is created while importing. The target system is, therefore, an Element ID master.
Importing a model where elements or objects have been removed will exclude them from the target system during import.
Model store
Transfers the entire application, all layers. This is, therefore, not equivalent to transferring a layer file in AX 2009. Moving one layer, moves everything in the layer, for example, all customizations written by the customer.
Element IDs are copied with the model store. The source system is, therefore, the element ID master.
Importing a model store replaces the target system's application code.
Element IDs are the granular level by which objects are identified, such as a field on a table (not each individual property) or methods on a class. The element IDs also create the link between the field in AX's data dictionary and SQL Server. This is stored in the SQL Dictionary, a table stored in the primary database (not model store database).
If the element ID for a field is changed (that is, if two fields swap their IDs), they will no longer match the SQL Dictionary. This risks data loss and at least some manual editing of this table to fix the link.
This is most likely to happen if you import the model store, which is why we will also refresh the primary database when we transfer the model store.
While developing code we have the following roles:
Software developers: They will begin with a copy of the live application and some business data to allow them to test their developments.
Unit Testing: This is performed on the development system to sign off a release into the user acceptance testing environment.
UAT: This is performed by end users and process owners and will require completed developments and recent business data.
For our deployment process, we also require the following:
Low risk
Does not add complexity, as this increases the risk of human errors or that the process is bypassed.
Allows efficient software development
Minimizes downtime in the production / live environment
Allows developer hot fixes to be applied to production
To accomplish this we have the following four environments:
In the proposal from Microsoft, the Test environment is also used for correcting mistakes that are then moved back to development. This does speed up the development of the system, but runs a risk of overwriting changes being performed in development.
The following diagram shows the process (reference Microsoft deployment guide):
All environments will be created from live/production (as described in Refreshing an Environment from Live), which creates our four environments discussed previously.
The process will be as follows:
A developer completes the development in the appropriate model in development. This should be unit tested at this point to reduce test iterations.
The model is exported to a disk as a build (which may be done off-site by the partner) and transferred to the Test (UAT) environment.
The model is imported into UAT and testing begins.
Corrections may be made by the developer (from the authoring organization in the original model) and then moved back into development. If so, the build is recreated and re-imported into test to ensure that no regression has occurred.
Model exported from test is ready for import into staging.
When the model is ready to move to production, staging is recreated from production.
The model is imported into staging, and the system is configured (new parameters, number sequences required, and so on by the development) and tested for regression.
The model store is exported from staging and imported into live
The required configuration data (which could be a job to recreate the configuration data) are also imported.
Periodically (especially after a hotfix or cumulative update is applied), the environments should be refreshed from production (which will mean data and model store databases). Having developments in progress should not delay this, as the projects can be exported and re-imported after the refresh is completed.
On occasions, the production system contains confidential information that should not find its way into the development environment. There is no standard method to do this, except for an update routine written to blank out the sensitive information. This should be considered along with whether this will hamper software development.