How we do AX releases – Part 1

“Good release management practices ensure that when your software is built, it will be successfully deployed to the people who want to use it. You have the opportunity to satisfy existing customers and hopefully to win new ones.”  It’s a statement coming from a excellent article dicussing 7 ways to improve your releases. Before continuing here, make sure you read the article entirely. It really deals with all of the facets of releases, starting from planning to infrastructure and automation of the process.

 

Let’s elaborate on a few of the topics in the article and explain how this series will provide a way of doing this for Microsoft Dynamics Ax releases (And remember: It will be A way to do it, not THE way):

 

  • Plan your releases!
    Captain obvious to the rescue.. But let’s be honest, how many of you technicals are often forced into a situation where an ad hoc release is asked…? So it is of the utmost importance to establish a regular release cycle. That way, all of the stakeholders have a clear view on the timetable and when to expect to see progress. Your release cycle is not about when your customer wants the release. It’s about when you can deliver it to the desired level of quality.One thing we have done to support planning releases and follow up the time spent on releases, is creating a custom work item type ‘Release’. On that custom work item type, we can put all the details concerning the release (Title, Original Estimate, Actuals, linked queries to be able to query for the work items related to this release)

 

  • Establish your release infrastructure early
    For Dynamics projects, this is even more important. Especially because a full Microsoft Dynamics AX environment requires quite some resources. This is one of the most difficult topics to discuss when it comes to figures. Having all of the needed environments (DEV, QA, UAT, STAGING, MIGRATION, PRODUCTION) will make you expensive as opposed to other vendors stating that a DEV, QA and PRD are enough. But in the end, the customer will notice during the implementation that he does need those to do things as they should be done.

 

  • Release notes are not optional!
    And yet I still come accross projects where releases are done without informing the customer what has actually been changed. And it’s all about perception here. You do not want all of the bugs to be on the notes, but the ones reported by the customer do need to be mentioned. That way, customers have the notion of progress and key users can be informed about the changes.To achieve this, we have done two things. First we have added a field Release note (No / Yes) to the work item types available on release notes. This way we can actually filter out the things we do not want on the notes. Secondly, we created a Visual Studio Team Explorer add-in to enable us to generate release notes based on a selected work item of the type Release. Through the use of the OpenXML SDK, we generate a word document containing a couple of sections and each section is linked to a work item query.

 

In the next post of this series, we will take a closer look at the custom work item type ‘Release’.

RM for VS2013 : Increase TFS deployment timeout

Today I saw that the TFS build had triggered the ReleaseManagement client but that it had failed. A closer look at it told me that TFS thought it had been waiting long enough and decided that the deployment failed. So I went to the ReleaseManagement client and tried to increase the timeout for TFS Triggered deployments. But the maximum value allowed in the client is 99 minutes. Yes… 99 minutes so clearly my AX deployment will take longer due to full compile, report deployment, portal deployment, …

RM_TFS_TimeOut

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

To get around this, you can skip the client and dive into the SQL database of ReleaseManagement. There is a table called SystemSettings which contains all of the RM settings. To get the timeout above the 99 minutes, just update the DeploymentStatusCheckMaxWaitInMinutes field with the value you need here.

 

UPDATE [ReleaseManagement].[dbo].[SystemSettings]
SET    DeploymentStatusCheckMaxWaitInMinutes = 180

Reopen the client and there you have it.

RM_TFS_TimeOut_180