Process of release build and deployment under control
Do you often struggle with sharing objects within one project in Microsoft Dynamics AX environment?
Is the amount of time and of energy spent on building and organizing new release builds and their deployment to target customer’s environment unacceptable to you anymore?
Do you and your customer often run into disagreements about ambiguities and bugs once the build is deployed?
If the answer is yes to any of these questions, then I have a number of tips based on my experience on how such situations can be avoided.
Decide what type of development environment is best suited to your project
When dealing with smaller-scale projects, with fewer developers involved and a lower likelihood that they will need to work on the same objects at the same time, you can use one shared development environment.
For larger projects use the model of distributed development environment in combination with Team Foundation Server.On the other hand for larger projects, you should use model of distributed development environments, in which each developer works on his own development platform that is regularly synchronized with the central repository (see below). Conversely, the developers also periodically submit their code to the central repository (usually on completion of a particular development task).
Utilize version management
Using version management on DEV environment brings a lot of advantages:
- It provides an overview of each change on each object, including a detailed change log
- It allows you to input a factual description to each object modification
- It allows you to be quickly up to speed on the whole history of changes on objects
- It significantly improves the effectivity of communication between developers working on the same project
Dynamics AX environment offers several possibilities of keeping track of development versions.
For each project, use at least two test environments. One of the main development branch, the other for hotfixes.When it comes to the model of shared development environment, it is advisable to use version management that is integrated directly within AX (MorphX VCS).
In this case the developer checks out an object upon starting his work, which makes it temporarily impossible for other developers to access this object for changes. Object only becomes available again after the prior developer checks in changes made to the object to the version management repository.
On the other hand, with the distributed model of development environment it is necessary to synchronize objects on developer’s local environment with the global repository. This allows the developers to work on the same object simultaneously. Conflicts may occur during the submission to the global repository, although for the most part these are automatically resolved. However, when an automatic solution is not possible, the developer has to resolve the pertinent conflicts manually.
For the global repository it is advisable to use Microsoft Team Foundation Server (TFS) that has, among other features, an integrated ticketing system, which allows managers to a see direct relations between the development changes and customer requests.
A clear overview of the history of requirements
Increased efficiency in communication and in execution
Collaboration and customer delivery team
Release to sell it without mistakes
Use a tool for release management in combination with a ticket system
Release management (RM) significantly raises work effectivity during the creation of a build that should be deployed first to TEST and finally to PROD environment. Apart from quick and smooth release creation, it also provides a clear overview of the detailed history of release build, as well as the list of the requests which were included in it.
From the outset it is clearly defined in the TS which tickets should be included in the build. Release creation process may subsequently proceed as follows:
- Release creator will check according to the ticket number whether it has an appropriate status in the TS and a development version for each related ticket is submitted to RM (ideally an automatic check functionality is utilized directly in TS)
- If everything is alright, he creates new build for release. Beforehand, he informs the customer and selected members of development team of this via email. The email should include all relevant information – especially the release number and the time interval during which the target environment availability will be limited. A special BUILD environment is used for build creation.
- Ideally, the delivery team has previously prepared PowerShell scripts which allow to program a sequence of steps for build deployment to target environment.
A simplified example of such a sequence may be: AOT compilation, Full CIL compilation, modelstore export, target AOS shutdown, import modelstore on target env., synchronize Data dictionary, start of target AOS, sending an e-mail to the customer and selected team members with the information about a successful deployment.
Differentiate between release creation and release deployment
When it is not possible to fully automate the process of build deployment, then the entire process of release creation and release deployment should not be left to a sole person. Due to the fact that deployment often takes place late at night, you will alleviate the risk of errors by distributing key roles between different team members.
The best way for release build creation is to engage one of the developers working on the project. He should be able to clarify many of the uncertainties related to submitted code and also comprehensibly and cumulatively hand over any required additional technical information related to the deployment (e.g. necessity to launch initialization jobs after release deployment, performance of changes in setup of planned jobs on Batch server, etc.).
The person in charge of the deployment does not necessarily need to be a developer, instead it can be another trained and reliable member of the Operations team.
Use TEST environment
Model of used environments is also associated with the release deployment process.
Besides the development environment (DEV), build creation environment (BUILD) and target production environment (PROD), it is also necessary to use a testing environment (TEST) before handing the final build over to the customer.
It is ideal to have at least two test environments. One allocated for testing of releases planned in TS in advance and second e.g. for the deployment of hotfixes. A second TEST should essentially be a copy of the production environment.
Engage customer into process of deployment
In order to avoid most of the confusion and unnecessary conflicts with the customer immediately after the release is deployed to the production environment (but also to TEST), it is important to set up a process through which the customer (the responsible key-user) is involved in the approval and testing of the requirements (tickets).
This may be achieved by workflow setup in the TS, set up in a way that the release to PROD is greenlit to deploy only after all the included tickets have the status “Tested and confirmed by customer”.
I believe that the above tips will help you to achieve greater customer satisfaction and also to raise the work efficiency of your team.
Vladislav Nový works as a Dynamics AX Developer in the company Blue Dynamic and has extensive experience with Dynamics AX development.