Upload
johnathan-watson
View
230
Download
0
Tags:
Embed Size (px)
Citation preview
Change management and deployment of Microsoft Dynamics AX 2012 modelsRobert BadawySenior Program ManagerMicrosoft Corporation
BRK310-R1
Disclaimer© 2012 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. Other names and brands may be claimed as the property of others.
Microsoft Dynamics AX 2012 R2 is a pre-release product under development. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft. Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. All product release dates and features specified are preliminary based on current expectations, and are subject to change without notice. Microsoft may make changes to specifications and product descriptions at any time, without notice.
Sample code included in this presentation is made available AS IS. THE ENTIRE RISK OF THE USE OR THE RESULTS FROM THE USE OF THIS CODE REMAINS WITH THE USER.
MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION. NO LICENSE, EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, TO ANY INTELLECTUAL PROPERTY RIGHTS IS GRANTED BY THIS PRESENTATION. Microsoft products are not intended for use in medical, life saving, or life sustaining applications.
Session Focus
Manage changes in a multiple developer AX
project
Create AX buildsDeploy AX
customizations
Deploy AX on staging and production systems
Best practices, illustrations, recommendations
DeploymentChange management
TFS integration, AX builds, models and model stores
Challenges
Assumptions
This Session Assumes the Following Audience is familiar with Microsoft
Dynamics AX Development, like the AOT, AX elements, and layers
Audience is familiar with source control and TFS
Audience is familiar with AX Models (Import/Export/Model files)
Audience is familiar with AX Model Store
Private AOS Topology with TFS• A private AOS topology is a setup where each developer has his or her own
Microsoft Dynamics AX client, AOS instance, model database, and business database.
• It is the recommended topology.• Artifacts are synchronized between developers using a supported version control
system:• Microsoft Visual SourceSafe, Microsoft MorphX VCS, Microsoft Team Foundation
Server (TFS)• This presentation will focus on TFS.
Shared AOS Topology• A shared AOS topology is a setup where all developers are sharing a common
AOS instance, model database, and business database.• It is supported but not recommended (see coming slide)
Development Topologies
Private AOS with TFS Topology
Shared AOS TopologyNot recommended, this session will focus on the private topology.
Potential issues:• Stale metadata or unpredictable
behavior on clients• Problems installing new solutions or
upgrading existing solutions, which may lead to corrupt data
• Unresponsive AOS while another user is debugging CIL code
• The need to frequently restart the AOS instance
When using this topology, we recommend you use MorphX version control system (VCS)For more details, refer to the white paper: http://technet.microsoft.com/en-us/library/hh352230.aspx
Development Lifecycle Flowchart
Administrator: Setup TFS
Administrator: Configure Version
Control for AX Development (Build
Computer)
Administrator: Add Model (s) to Version
Control (Build Computer)
Administrator: Apply a Label to Latest
Version of Source Files
Administrator: Create AX Build
(Build Computer)
Periodic
Developer: Deploy Build
As needed
Developer: Check out, Check in and
Get Latest
Need new clean build?Yes
Developer: Synchronize to
Latest
No
Developer: Configure Version
Control on Developer Computer
Creating AX Builds
Create an AX Build on Build Computer An AX Build is created from a collection of source files in the central TFS
repository (XPO files, VS Projects, label files). File versions corresponding to a particular build all share a common “label”.
Source files that share a common label constitute a specific version of an AX model or application.
Any Developer should be able to deploy a specific AX build or synchronize their AX environment to that build.
It is recommended to dedicate a one-box installation of AX to be a build computer, where an administrator creates daily/periodic builds of the AX application.
Creating AX Builds: Core Steps (1)1. Sync your local repository files to the latest version of your
model(s) files• Use Team Explorer or use the TFS get command
2. Set the build label (Take a snapshot of your files)• Example: tf label “1.0.0.101” c:\<ProjectName>\
PrimaryAXApplication\ModelA /recursive 3. Stop the AOS4. Delete the current version of your models5. Start the AOS6. Synchronize the business database• ax32.exe startupcmd=synchronize
7. Stop the AOS8. Create new blank models
Creating AX Builds: Core Steps (2)9. Generate the combined import XPO artifact from the individual XPOs
(Use the tool combineXPOs.exe)10. Start the AOS11. Load Label (.ald) files into AX when applicable
ax32.exe -startupcmd=aldimport_<label_file>12. Load combined XPOs into AX using ax32.exe
ax32.exe -aol=%LAYER% -development [email protected] -startupcmd=autorun_Import.xml
13. Review compile errors in import log %USERPROFILE%\Microsoft\Dynamics Ax\Log\allimport.log
14.Build and import AX Visual Studio projects (using MSbuild) when applicable
15.Compile the application, including CIL compilation16.Run database synchronization (DB sync), as above17.Export your model(s) to a model file(s).
AOT context menu > Check-out
Using TFS Integration Features(1)
Check out corresponding XPO
file in local TFS repository for
editing
Enable the element for editing in AX
developer workspace
Start End
AOT context menu > Check-in
Export element to corresponding XPO
file in local TFS repository
Check-in XPO file to TFS central repository
Disable editing of element in AX
developer workspace
Start End
AOT context menu > Get-latest
Using TFS Integration Features(2)
Synchronize corresponding XPO
file in local TFS respository
New version exist in central TFS repository?
Update local XPO file with new version
and load in AXYes
End
No
EndStart
Note: If the local version of the file is already up to date, “get latest” does not load the file into Microsoft Dynamics AX. Microsoft Dynamics AX and the local TFS repository should always be in sync. If you have synchronized the XPO file from outside the Microsoft Dynamics AX environment (by using Team Explorer or another tool), you must manually load the XPO into Microsoft Dynamics AX.
Version Control > Synchronize
Using TFS Integration Features(3)
Synchronize all out-of-date files in the
local TFS repository folder of the
selected model
Combine all updated files in a common
XPO (Files that were not
updated are not included in the XPO)
Start
Load and compile combined XPO
Update synchronize log
End
Version Control > Synchronize Considerations• Errors may occur when you use Version Control > Synchronize depending on the scale
and state of the source repository at the moment of synchronization
Errors may put your system in a state where you are blocked from checking files out of TFS or checking them in to TFS.
If you cannot use TFS features from the Microsoft Dynamics AX development workspace after a synchronize error, delete the contents of the Microsoft Dynamics AX SysVersionControlSynchronizeLog table to recover from this condition.
• If a file’s version in the local repository folder is already equal to the latest version in the TFS central repository (that is, it does not need to be updated), that file is not loaded into Microsoft Dynamics AX when you synchronize (unless you use the “force” option)
Using TFS Integration Features(4)
Change management and TFS integration for multi-developer projects (white paper)• This white paper describes in details tasks and best practices that are related to
development life cycle management in Microsoft Dynamics AX 2012
• It focuses on TFS integration, creation of AX builds, and deployment on development environments.
• It has been released on information source and can be downloaded from here.
Windows PowerShell® (PS) Scripts• PS scripts that create and deploy AX builds have been released and are located in
the Windows PowerShell gallery.• Scripts can handle multiple models, multiple layers, and dependencies on external
models and assemblies
Development Lifecycle: More Details?
Typical Application Lifecycle Flowchart Development
EnvironmentsTest Staging
Production Env .
Develop AX solutions/customizations
Deploy, test, Make changes
Initialize from production, deploy, test, prepare for
production
Export Model
Deploy, operate
Export model store, configuration
Re-base staging env.
Disk repository of released AX
models
Create Builds
Apply changes back
Some Background: Element IDs (1)
Model Store
Business Data
AX Element MetadataAX Element ID 1
Origin GUID Legacy ID
DataID1
• AX elements (Metadata) are associated with corresponding business data based on their element ID.
• Element IDs are specific to each installation and are sometimes referred to as installation-specific IDs.
• When two AX environments share copies of the same business data (Such as transaction, configuration or master data), these environments need to also share the same element IDs
How element IDs are assignedDuring import of model files and XPO files, element IDs are assigned based on 4 rules in the following order:
• If an element already exists that has the same Origin value as the imported element, replace the existing element and reuse its element ID.
• Otherwise, if an element already exists that has the same Type, Name, and ParentID value as the imported element, replace the existing element and reuse its ID.
• Otherwise, if the imported element has a LegacyID value > 0, and the same LegacyID value is available on the target system, then set the element ID to be equal to LegacyID.
• Else, assign a new installation-specific ID from a guaranteed free range that does not collide with any LegacyID values
Some Background: Element IDs (2)
Some Background: Artifact Types XPO files Model files Model store files
Installation tool AX development workspace (MorphX)
AXUtil.exe or Windows PowerShell cmdlets
AXUtil.exe or Windows PowerShell cmdlets
The files can be signed?
No Yes No
Element IDs are preserved on target model store?
All elements that already exist in the model store preserve their IDs (XPO files don’t contain IDs). For new elements, new IDs are generated.
All elements that already exist in the model store preserve their IDs. For new elements, new IDs are generated.
All element IDs on target system become equal to IDs store in the model store file.
Compilation is required after installation?
Yes Yes No
CIL generation is required after installation?
Yes Yes No
Deploy Models on
a Test Environm
ent
Publish to Servers (when applicable)
Deploy and Compile
Prepare Environment for Deployment
Drain users, reject new
clients
Close active sessions
Stop all AOSinstances
Create Role Centers from
AOT
Publish Enterprise
Portal content
Publish reports
Publish cubes
Delete Current
Version of Models
Start single AOS
Synchronize database
Stop the AOSImport Models
Start single AOS
Compile the application, including CIL
Synchronize database
Start
End
Start all AOS instances
Initialize Staging Environment from Production System
Initialize Staging Environment from Production
Export model store of staging
system to backup file
Export model store of
production system
Import model store file
from previous step
on staging system
Start AOS on staging System
Synchronize database on
staging system
Stop AOS on Staging System
Start
End
Do Not Delete Models on the Staging System!• Same procedure used for deploying models on a test environments
• One important exception: Skip the step where you delete the current version of your models in order to maintain common element IDs with the production system.
Deploy Models on a Staging Environment
Prepare the Staging System for Production
Export metadata and configuration data on staging system
Export workflows
Export integration points data
Export model storeStart End
Deploy on the
Production
Environment
Finalize Deployment
Publish to Servers (when applicable)
Deploy Metadata
Prepare Environment for Deployment
Drain users, reject new
clients
Close active sessions
Stop all AOSinstances
Create Role Centers from
AOT
Publish Enterprise
Portal content
Publish cubes
Clean up old model
schema (if applicable)
Accept new clients on
AOS
Start all AOSinstances
EndImport model store
Start single AOS
Start AX client
Synchronize database
Start
Import configuration data (when applicable)
Import integration
ports
Import workflows
Publish reports
Import model store with minimal downtime Run the schema command to create a new schema.
AXUtil schema /schemaname:%NewSchema% /db:%TargetDatabase%
Import the model store into the temporary schema.
AXUtil importstore /file:%AxModelStoreFile% /schemaname:%NewSchema% /db:%TargetDatabase%
When all users are out of the system, stop the AOS instance
Apply the changes to the model store to move from the temporary schema to the dbo schema.
AXUtil importstore /apply:%NewSchema% /db:%TargetDatabase% /verbose
Deploy on the Production Environment
Production and staging model stores can lose element ID commonality:• Model store files cannot be used to deploy metadata when the source and target system
don’t have common element IDs.
• Even if the staging environment was originally based on the model store of the production system, some scenarios may lead to loss of element IDs commonality, examples are:
Importing new elements (using XPOs or model file) or creating new elements on the production system
Deletion and reinstallation of models. This will regenerate new element IDs.
Installation of a model store on the staging environment from a different source than the original model store.
• You will then need to re-based the staging system from the production model store as described next.
Re-base Staging System from Production
Re-base Staging System
from Production
Publish to Servers (Staging)
Re-base Staging Metadata from Production
Prepare Staging System
Drain users, reject new
clients
Close active sessions
Stop all AOSinstances
Create Role Centers from
AOT
Publish Enterprise
Portal content
Publish reports
Publish cubes
Staging: Export your model(s) to model file(s) **
Production system:
Export model store
Staging: Import model store file from previous step
Staging: Import model files from first
step
Staging: Start the AOS
Staging: Compile the application, including CIL
Staging: Synchronize
database
Start
End
Staging: Start all AOS
instances
Deploying Customizations Across Microsoft Dynamics AX 2012 Environments (White paper)• This white paper covers in details the recommend deployment procedure of metadata
across different AX environments.
• It can be downloaded from here.
• A new version of the paper has been uploaded on October 19, 2012.
Deployment of Metadata: More Details?
Related SessionsEarlier Today (Tuesday) BRK305, Setup, Manageability & Deployment of Dynamics AX 2012, 13:15 – 14:30 BRK304, Inside the Microsoft Dynamics AX 2012 User Interface for Developers, 10:30 –
11:45
Wednesday BRK315, Pushing the envelope of Business Application Development in Dynamics AX BRK307, Implementing a Business Intelligence solution with Dynamics AX 2012 R2 BRK306, Extending the reach of your Dynamics AX 2012 application with Enterprise Portal BRK321, Dynamics AX 2012 Security - Planning and developing for an implementation
Thursday BRK308, Developing cool new Visualizations and powerful Reports with Dynamics AX 2012
R2 BRK314, Integration Dynamics AX with other Line of Business Applications
Links
CombineXpos tool http://informationsource.dynamics.com//
RFPServicesOnline/Rfpservicesonline.aspx?ToolDocName=Microsoft+Dynamics+AX+2012+Combine+XPO+Tool+Beta+1.0%7cQJ4JEM76642V-8-1002
Deploying Customizations Across Microsoft Dynamics AX 2012 Environments (White paper) http://technet.microsoft.com/en-us/library/hh292604.aspx
Change management and TFS integration for multi-developer projects (white paper) http://technet.microsoft.com/EN-US/library/jj713631.aspx
© 2012 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.