Another follow up post, this time to the one on MSDeploy. As I said in that post a better way to trigger the MSDeploy PowerShell script would be as part of the build workflow, as opposed to a post build action in the MSBuild phase. Doing it this way means if the build failed testing, after MSBuild complete, you can still choose not to run MSDeploy.
I have implemented this using an InvokeProcess call in my build workflow, which I have placed just before Gated checking logic at the end of the process template.
The if statement is there so I only deploy if a deploy location is set and all the tests passed
BuildDetail.TestStatus = Microsoft.TeamFoundation.Build.Client.BuildPhaseStatus.Succeeded And
String.IsNullOrEmpty(DeployLocation) = False
The InvokeProcess filename property is
BuildDetail.DropLocation & “_PublishedWebsites” & WebSiteAssemblyName & “_Package” & WebSiteAssemblyName & “.deploy.cmd”
Where “WebSiteAssemblyName” is a build argument the name of the Project that has been publish (I have not found a way to automatically detect it) e.g. BlackMarble.MyWebSite. This obviously as be set as an argument for the build if the deploy is to work
The arguments property is set to
“/M:http://” & DeployLocation & “/MSDEPLOYAGENTSERVICE /Y”
Again the “DeployLocation” is a build arguement that is the name of the server to deploy to e.g. MyServer
The Result property is set to an Integer build variable, so any error code can be returned in the WriteBuildError
This seems to work for me and I think it is neater than previous solution