There are many scripts to help us build the solution, which can be very complicated. To get us started, the following scenario can work well for many implementations.
In this scenario, we have several developers working on a solution for the VAR, and a team of two working on security and reports in the USR layer.
The customer's environment consists of the following:
- A shared development server or a VM for each developer
- A build sever
- A test server
- The production or live server farm
The VAR's environment will consist of these:
- A virtual machine for each developer (and also per customer they are working)
- A build server, which also acts as a unit test machine
The process starts at the VAR when all developers have checked in the code-complete unit tested code. The following steps cover the general process:
- The build server at the VAR will be rebuilt from an AX 2012 VM template of the correct service pack level.
- It will then be configured to link to the TFS repository.
- The developer will then navigate to Version Control | Synchronise, check Force in the dialog, and press OK.
- This will be repeated for each model.
The models will then be exported and delivered to the customer's site. At the customer's site, the following steps are performed:
- The customer's build server will be refreshed from live (using database backup and restore for at least the model store database, and the business database too if policies allow).
- The models will be installed from the VAR.
- If using version control, one developer will synchronize his/her virtual machine with source control.
- The models will be exported from the developer's VM or the shared development environment.
- The models are then imported into the build server and then fully compiled.
- The test server will be refreshed from live using database backup and restore of both the databases (the baseline is not relevant for this).
The model store can now be moved to test in its entirety. This is because the build server was refreshed from live, and therefore, the element IDs will match the live server. Importing models will only create element IDs if they don't already exist. Once we have performed our user acceptance test in test, it can then be deployed in live.
This is a simplistic method, which avoids the use of build scripts. Build scripts may seem complicated, but once they are set up, the whole process can be automated. The following material is useful for more detail on the best practices with source control as well as for creating your own automated build process:
- Build and deploy scripts for Microsoft Dynamics AX 2012: https://gallery.technet.microsoft.com/scriptcenter/Build-and-deploy-for-b166c6e4
- Change management and TFS integration for multi-developer projects (white paper) [AX 2012]: http://technet.microsoft.com/en-us/library/jj713631.aspx