How to deploy a service application from the VSTS pipeline?

Question

I configured the CI assembly for the Service Fabric application in Visual Studio Team Services according to this documentation: https://azure.microsoft.com/en-us/documentation/articles/service-fabric-set-up-continuous-integration p>

But instead of having my CI assembly do the publishing, I only do the Build and Package tasks and include all the output related to the Service Fabric, such as the pkg folder, scripts, publishing profiles and application settings. That way, I can transfer it along with the new release pipeline (agent-based releases) to actually deploy my application for services.

In my release definition, I have one Azure Powershell task that uses an ARM endpoint (with the settings for the corresponding service managers).

When I deploy my application to an existing service cluster cluster, I use the default Deploy-FabricApplication cmdlet, which goes through the pkg folder, and the publishing profile configured to connect to the existing cluster.

Release failed with error message "Cluster connection instance is zero." And I don’t understand why?

While doing some debugging, I found that: The Deploy-FabricApplication cmdlet runs the Connect-ServiceFabricCluster cmdlet as accurately as possible, but as soon as the Publish-NewServiceFabricApplication cmdlet starts, the cluster connection will be lost.

I would expect this scenario to be possible using service cmdlets, but I cannot figure out how to keep the cluster connection open during deactivation.

UPDATE: the documentation link no longer refers to powershell Service Fabric scripts, so the precondition for this question is no longer documented. This article now discusses VSTS build and release tasks, which may be preferable to the powershell cmdlets I tried to use.

Answer 1

When the Connect-ServiceFabricCluster (from Deploy-FabricApplication.ps1) is called, the local $clusterConnection variable is set after calling Connect-ServiceFabricCluster . You can see that using Get-Variable .

Unfortunately, in some SDK scripts, there is logic that expects the variable to be set, but since they work in a different area, this local variable is not available.

It works in Visual Studio because the Deploy-FabricApplication.ps1 script is called using dotted source notation , which puts the $clusterConnection variable in the current scope.

I'm not sure if there is a way to use the point source when running the script, although in the release pipeline, but as a workaround, you could make the $clusterConnection variable global right after setting it through the Connect-ServiceFabricCluster call. Modify your Deploy-FabricApplication.ps1 script and add the following line after the connection logic (~ line 169):

 $global:clusterConnection = $clusterConnection 

By the way, you might consider setting up custom build / release tasks that deploy the Service Fabric application, instead of using various Deploy-FabricApplication.ps1 scripts.

Answer 2

Try using the PowerShell task instead of the Azure PowerShell task.

Answer 3

There is now a built-in VSTS task for deploying the Service Fabric application, so you no longer have to worry about running the PowerShell script yourself. The task documentation page is located at https://www.visualstudio.com/docs/build/steps/deploy/service-fabric-deploy . An original CI article has also been updated that provides detailed information on how to configure everything: https://azure.microsoft.com/en-us/documentation/articles/service-fabric-set-up-continuous-integration / .

Answer 4

Today I faced the same error and opened the GitHub problem here

On the side of the note, the VS script created by Deploy-FabricApplication.ps1 uses the module

"$((Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Service Fabric SDK" -Name "FabricSDKPSModulePath").FabricSDKPSModulePath)\ServiceFabricSDK.psm1"

This is where Publish-NewServiceFabricApplication . You can test the deployment logic and rewrite it more intelligently using the ServiceFabric lower-level SDK cmdlets (perhaps getting a connection using Get-ServiceFabricClusterConnection instead of global use)