Compress application binaries

[nehmebilal]

At the moment, we upload / download application binaries file-by-file to / from blob storage. It would be good to have the option of uploading a compressed package that will then be downloaded by each VM and decompressed before starting the app.

As discussed below, we're also considering using NuGet for packaging and possibly as an alternative to blob storage.

Thanks to @galvesribeiro for the suggestion.

[dealproc]

Considering that there is already a document format for this, it may be beneficial to invest in using the nuget package format for this feature. I've done some work of this nature with some auto-update of windows services work a few months back, and it was quite nice to use. This would provide versioning information, etc. about the compressed app binaries as well.

[nehmebilal]

Hmm I don't see how that is possible. Unlike NuGet, the way packages are deployed in Yams is described in one central file 'DeploymentConfig.json'. There is no notion of package dependency neither.

[dealproc]

In this model, you follow similar ruling to what is done with Squirrel.Windows. You package everything you need for the applet into the single .nupkg and you extract that on disk somewhere to be used. I'd need to better understand the "DeploymentConfig.json" before I could advise further.

[jkonecki]

I don't think any changes to DeploymentConfig.json would be needed. If the content of the folder in blob storage is a single NuGet package than after downloading it locally an additional step of extracting the package could performed.
Octopus Deploy goes a bit further with only copies delta of binary difference between previous and current package. That feature is more advance, but for the time being copying NuGet packages only would be very nice.

[nehmebilal]

I don't think any changes to DeploymentConfig.json would be needed. If the content of the folder in blob storage is a single NuGet package than after downloading it locally an additional step of extracting the package could performed.

What would be the advantage of using NuGet in this case over let's say a zip file?

Octopus Deploy goes a bit further with only copies delta of binary difference between previous and current package. That feature is more advance, but for the time being copying NuGet packages only would be very nice.

YamsDeploy also does that.

[jkonecki]

Since NuGet is a zip file essentially there wouldn't be a huge adventage apart from the fact that a lot of build piplines already utilises NuGet format for packaging applications. Everyone using Octopus Deploy already has a NuGet package for their application so being able to publish it easily without any further steps would help with adoption.

[nehmebilal]

That makes sense. The additional step of extracting the NuGet package should be as easy as extracting a zip (assuming there is a library that knows how to do it). We could have support for both .zip and .nupkg.

We could even go a step further and support NuGet feeds as an alternative to blob storage (which can be done by implementing a new storage provider) but the DeploymentConfig.json still need to be stored somewhere. It might be a sign that the DeploymentConfig.json and packaging applications should have separate Apis.

[jkonecki]

Agree. NuGet storage provider sounds like a great idea - it will simplify deployment considerably.

[dealproc]

Take a look at this to "deploy" the nuget package:
https://github.com/dealproc/Drey/blob/master/source/Drey.Configuration/ServiceModel/ReleasesPollingClient.cs#L156

[jkonecki]

Another benefit of a package is storage maintenance - I just had a 'pleasure' of deleting tens of thousands of files and it does take ages, even with Storage Explorer parallelizing requests.