Every implementation project involves separate Dynamics AX environments for developing customizations, testing, and then finally releasing these customizations into the production environment. The Application Lifecycle is the process of governance, development, and maintenance of the customization process across these environments.
The following image shows an example application life cycle scenario for customization and code promotion across environments, using Dynamics AX:
As shown in the preceding flowchart, this example ALM process goes through the phases described in the following sections.
In this phase, the development team creates a customized solution, does unit testing, and when the code is ready for testing, the code is checked into the development branch of the version control system. When the changes are ready to go to the test environment, they are merged with the main branch. A build is created out of the main branch and released in the test environment. Any defect found during the testing cycle is fixed and is checked into the version control system. It then goes through the merge process and is released to the Test environment.
The build server collects the latest XPO (.XPO is an extension for the code files exported from Dynamics AX AOT) changes from the TFS version control main branch and creates build for the test environment. The output of a build would be a model store file.
During this phase, custom solutions are tested end-to-end, ideally by a quality analyst. Defects are raised and assigned to the respective developers. The code changes made by the developer are checked in into TFS, and a new build is created and applied on the test environment. The quality analyst retests the process, and closes the defect when satisfied.
When all the testing efforts have been completed, there are the following options to create the build for production:
- Export the model store for the QA environment and deploy to the production environment
- Create a release branch in TFS and create a build out of the release branch for production release
The following are some common guidelines and recommendations for the ALM process:
- Use version control and appropriate branching strategy for the development process.
- Implement a code review process to manage check-ins and control what needs to be released to the test environment.
- Implement comments during code checking, providing a brief description of the code, the linking feature, or defects to track the changes appropriately.
- Implement the formal release process (cadence of releases, manager approval, and so on) to avoid destabilizing the test environment due to frequent releases.
- Use the build server and build automation scripts to create an automated build creation and build deployment. There may be some initial investment to get the things in place, but it saves a lot of time during the testing phase of the project.
- Use the Microsoft guidelines for deployment in the test and production environments. Follow the Microsoft white paper, Deploying Customizations Across Microsoft Dynamics AX 2012 Environments at https://www.microsoft.com/en-us/download/details.aspx?id=26571.
- Avoid moving the code using XPO from the development to test or the production environment. Importing new objects using XPO can lead to object conflict during model store import.
- Do not modify the code directly in test or production environment; it's bad practice, and can create confusion and code loss. It is easy to miss merging the code back to version control properly and the next build deployment will override the changes.
- If not using build automation, keep a clean development environment, synced with the latest code, to create build manually and to promote the code to test and other environments.