[ServiceFabric] Continue on 'Application type and version is still in use'

[NickDarvey]

Can an option be added to let us continue on an Application type and version is still in use error? (Pretty please.)

Usage A: Combined releases
We have multiple Service Fabric applications and we'd like to bundle some of them so that they're released together. Most of the time, only one application (App A) has been updated whilst the other remains on the same build (App B). App A's new build triggers a new release and executes the deployment tasks for both App A (with the new version) and for App B.

Usage B: Redeployments
Occasionally, a deployment may partially succeed (maybe some documentation didn't finish uploading) but everything else went out alright. It'd be great if we could just tap 'redeploy' without having to disable the Service Fabric task (which is our current process, because everything else acts idempotent'y except that one.)

It would be lovely if the Service Fabric deployment task had an option of not erroring if a type and version already exists.

(Let me know if I can provide any more info or justification.)

[mikkelhegn]

Hi Nick, we have no current plans to change the deploy task, but are happy to take in pull requests for additional / enhanced features.

[mikkelhegn]

Hi @NickDarvey: Take a look at this PR by @mikanyg: #3382 He added ability to control the overwrite behavior. Will that do the trick?

[mikanyg]

@NickDarvey and @mikkelhegn I'm actually "brewing" on a new pull request to have an option to skip upgrades if same app type and version exists.
For new deployments, setting the OverwriteBehavior option to 'Always' will do the same trick.

Stay tuned

[NickDarvey]

That'd be amazing @mikanyg --- ARM templates give us idempotent infrastructure deployments, it'd be great to have the same with our SF app

[mikkelhegn]

@mikanyg: Our thinking has been along the lines of putting in this logic:

Create/Upgrade modes:

• Replace (no matter what or if same type and version)
• Make it run (upgrade if exists otherwise create new one)
  • What if we have no upgrade parameters (default to Monitored?)
• Upgrade Only (upgrade if one exists, otherwise do nothing)
  • What if we have no upgrade parameters (default to Monitored?)

[mikanyg]

@mikkelhegn Looks promising, some of the logic is already there as I see it.

• Replace: Can be achieved by disabling upgrades and setting OverwriteBehavior to Always

• Upgrade only: The PR I'm working on will add option to make upgrades idempotent, by skipping the upgrade if the error mentioned occurs.

• Make it run: I previously did this using the Deploy-FabricApplication.ps1 found in the .sfproj Scripts folder, following this blogpost by Colin Dembovsky, but that was prior to the ServiceFabricDeploy task was made available.

Regarding default to Monitored, I think that it's the best option, but should still be configurable.

Overall I think that capturing all the different deployment scenarios in a single task is quite hard, but using the visibleRule you could probably have the task show only relevant options based on initial deployment mode. But focus should be on idempotency, since the task will often be part of a longer deployment workflow, and any failures in subsequent tasks might mean that a redeployment is needed (could be a transient error causing failure in other task).

Personally I like playing with all the parameters in the underlying powershell scripts, and was even thinking about exposing the Action parameters. In some advanced scenarios a deployment might be split up so Register is a seperate step and then initiating a Create/Update action is something that requires approval or manual intervention.

[mikanyg]

@NickDarvey a new option, SkipUpgradeSameTypeAndVersion has been merged to master in PR #3529, hopefully it will show up in VSTS soon.

[NickDarvey]

Awesome, thank you @mikanyg