Differential packaging

Question

When upgrading an application, the Test-ServiceFabricApplicationPackage command throws errors for every code package whose version number has not changed (it's saying the content has changed, even though the code hasn't). I know there is a feature that allows creating partial packages, but I was not able to use it. My questions are:

1. How is the content of the code package checked for changes? Binary comparison?
2. How to construct the partial package (Just remove the Code directories after VS builds the package? Edit the ServiceManifest.xml file?)
3. How to run Test-ServiceFabricApplicationPackage (What's the image store URL? How to pass that parameter to the standard deployment script?)

I'd appreciate a thorough example.

Answer 1

If you want to do partial upgrades, this is how I've done it:

Given

app1 1.0.0
  service1 1.0.0
    code 1.0.0
    config 1.0.0
  service2 1.0.0
    code 1.0.0
    config 1.0.0

And you want to update only Service 1 to version 1.0.1 as shown below:

app1 1.0.1
  service1 1.0.1
    code 1.0.1
    config 1.0.1
  service2 1.0.0
    code 1.0.0
    config 1.0.0

In your Service1, update the ServiceManifest.xml to have correct version numbers (the service itself and the different packages you want to upgrade). Then, in your service2 folder, delete everything except the ServiceManifest.xml.

In your ApplicationManifest.xml, you should keep the ServiceManifestImport for Service2 at version 1.0.0. Also update the versionnumber for ServiceManifestImport for Service1.

After that is done, you should be able to do a:

Test-ServiceFabricApplicationPackage $packagePath -ImageStoreConnectionString $ImageStoreConnectionString

to validate that the package works. What this does (as far as I understand) is it uses the local package along with the currently deployed package, and those two combined should then equal a valid complete package.

So, basically, the only thing that changes is:

• You remove the things you don't want in your package (but you keep the ServiceManifest.xml)
• You update the version numbers in the services that have changed
• You update the version numbers in the application manifest for both the application, and the changed services.

Also, see this documentation: https://azure.microsoft.com/en-us/documentation/articles/service-fabric-application-upgrade-advanced/#upgrade-with-a-diff-package

Regarding getting the image store to use for the Test-ServiceFabricApplicationPackage call (you can find it all by looking at the default deploy scripts, but here's what you need):

Open powershell
Connect to your cluster (Connect-ServiceFabricCluster ...)
Execute the following commands:

$ClusterManifestRaw = Get-ServiceFabricClusterManifest
$ClusterManifestXml = [xml]$ClusterManifestRaw
$ManagementSection = $ClusterManifestXml.ClusterManifest.FabricSettings.Section | ? { $_.Name -eq "Management" }
$ImageStoreConnectionString = $ManagementSection .ChildNodes | ? { $_.Name -eq "ImageStoreConnectionString" } | Select-Object -Expand Value

Answer 2

Service Fabric supports differential packages but upgrades with differential packages hasn't been completely integrated with Visual Studio yet. But you can do it manually.

1. Yes it's binary comparison.
2. So in a differential package, you increment the versions only for packages (code, config, and data) that have changed. If the binaries have changed for a package whose version has not changed - which can just be from a recompilation - then you can simply omit its files from the final application package.
3. The image store can be an external location (like Azure blob storage) but the simplest option is the built-in image store service, which is used by default in the SDK and in Azure. To use that, simply use "fabric:ImageStore" for the image store string: Test-ServiceFabricApplicationPackage -ApplicationPackagePath /path/to/package -ImageStoreConnectionString fabric:ImageStore

Here's an example of a diff package. Imagine you have the following:

app1 1.0.0
  service1 1.0.0
    code 1.0.0
    config 1.0.0
  service2 1.0.0
    code 1.0.0
    config 1.0.0

And you want to upgrade only the code package of service1:

app1 2.0.0            <-- new version
  service1 2.0.0      <-- new version
    code 2.0.0        <-- new version
    config 1.0.0
  service2 1.0.0
    code 1.0.0
    config 1.0.0

You update the versions in your application and service manifests, but you only include the packages that have changed in the final application package. Your application package would simply look like this:

app1/
  service1/
    code/

The packages whose version numbers haven't changed aren't included. Note that you could include those packages, but only if they are identical (binary diff) to the packages of the same version currently registered for the application in the cluster, in which case they will simply be ignored.

A quick and easy way to generate one of these is to use the Package command in Visual Studio (right-click the application and select Package). Then go to the output directory and simply delete the directories for packages whose versions haven't changed.