For a Service Fabric project I’ve been working on, the project team has implemented a release management pipeline in Visual Studio Team Services.
When a commit is pushed to the master branch, the build is run and (if succesful) a release is created and automatically deployed.
The release pipeline basically does two things: 1) make sure the environment is up to date using some ARM templates and 2) upgrade the Service Fabric application to the new version.
Upgrading the application requires that you increment the version numbers in the application and service manifests.
One way to deal with this is simply by incrementing the version number of each service whether or not it has actually been modified.
You can do this by using an auto-generated build number as explained in Colin’s blogpost.
In a lot of situations this works fine because Service Fabric allows for zero downtime deployments.
However, we needed to be sure that some services aren’t unnecessarily upgraded.
Some of the stateful services in the application maintain connections to external hardware devices.
We don’t want to interrupt these each time we need to roll-out a change in any of the other services.