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

 

Release Management for VS2013 … and AX : Part 1

In a previous post I mentioned Release Management for Visual Studio 2013 but I didn’t take the time to go through the capabilities and why I was using it. We have spent some time on creating automated builds for AX and these are up and running for while now using the code activities from Joris De Gruyter. Right now I am working together with my colleague Kevin Roos to investigate more automated deployments with AX2012 R3. Along the road, I hope to find the time to write some posts that provide you with some insights along the way. This post is the first of them.

So the first thing we thought of, is deciding which toolset we would be using. We didn’t want to invent hot water again and yet, most of the things available have their limitations. So a few brainstorm sessions later, we decided to go for the following set of tools:

Release Management for Visual Studio 2013

Formerly known as InRelease, Microsoft bought this solution from InCycle and incorporated this with the Visual Studio 2013 stack and named it Release Management for Visual Studio 2013. RM helps you to deploy your solutions accross the different stages in their lifecycle.

The pros are:

  • The tool enables the definition of environments, servers, environment stages to work on
  • A workflow based way of deploying between environment stages
  • The ability to create custom tools be used within deployments
  • Template designer to easily drag and drop servers, actions, … in your release templates.
  • Tight integration with TFS Builds (Deploy build outputs, trigger deployments from successful builds, …)

The cons:

  • The first and farmost the biggest downside of RM is the fact that the tools and actions used within release templates are not using the same type of activities as the TFS build CodeAcitivity types.
    It would be nice if Microsoft would add the possibility to use code activities as they are working on the product now. Then it would be possible to work on code activities that can be reused for both TFS Builds and RM Releases. (And we could again make use of the code activities Joris created)
  • The second con might only be clear to people already using RM. The RM client could use a more user friendly way of working your way around the different sections. I know this is not a big deal, but let me give an example of this. When deleting an action, you need to go through all of the templates manually to remove it before you can actually remove the action / tool. A reference tool or cascade remove would be nice 🙂

DynamicsAxAdmin sources (from Joris’ CodePlex)

Joris De Gruyter has created a set of code activities that can be used as TFS Build Activities and along with those activities, he has a whole set of tools and plumbing code that can be reused. And the most important thing here for us are the PowerShell CmdLets that are also available in his solution on codeplex. An good example of a useful CmdLet is the Get-ClientConfiguration CmdLet which will try to find the client configuration via registry, file, … and get all of the details like binary folders, installation directory, and so on. So along the way, we will try to reuse some of those CmdLets.

Dynamics Ax 2012 Management utilities

The management utilities will also be used to reuse the CmdLets from Microsoft to get stuff done in the model store, deploying reports, deploying portal, …

PowerShell module and ‘wrapper’ scripts

To do most of our own plumbing, PowerShell will be used. The idea is to create a PowerShell module that contains reusable functions to work with Dynamics Ax. This module will be used by the various tools and actions that we will within RM. Next to the module, we will create a few tools within RM and each of these tools will have a ‘wrapper’ PowerShell scripts that will look at the different actions that can be performed with that tool and the parameters used for these various actions. The reason for splitting into different tools is easier management from within RM and cleaner PowerShell files with seperation of concerns.

So all of the above results in the following overview.

ReleaseManagementVS2013_Overview

Let’s take a look at the cleaning of AX artifact folders  to understand a bit more of what is going on there. The idea is to create a tool that  can be used by several actions. For the cleaning of artifact folders, we only have a 1-1 relationship between Actions and Tools. The AX Folder cleaner tool actually runs powershell and uses attached resources (powershell files) to do the work. All of the actions that use the tool can use these same resources but have a different command line to run them. More technical details on what is going on exactly will follow in the next post.

Release Management – Customize timouts on default tools / actions

In Release Management for Visual Studio 2013, you can customize your tools and actions to work with. The last few days I was creating a Release template for use with Dynamics AX 2012. One of the actions early in the template is backing up the database. ( Of course you need to backup first 🙂 ) And there I faced a little inconvenience: I could not adjust the timeout of the restore action but this was needed as an AX model store database restore could not be completed within 5 minutes.

So I decided to go back to the Restore SQL Database action and adjust the timeout setting. But hey, you are unable to do that on the default tool!

DefaultTimeout

There is a parameter to setup default timeouts, but this only applies when creating new actions. So that doesn’t help a lot.

DefaultTimeoutAdminSetting

So for me, the most convenient and simple solution was to copy the tool that is available out of the box and create a new one from it. Then you do have the ability to set the timeout.

CopyTool

CopyTool2