ASP.NET vNext deployments

thoughts.md

Given this scenario:

We have an ASP.NET vNext web app that we build once, and then deploy to 5 separate servers running IIS.

With old ASP.NET it's pretty easy - we can publish it to a folder, then xcopy the files to each IIS server. The publish directory would just contain the views, config files, assets, and a few DLL's in the bin directory. We can clearly say "this is the best way" and not worry about much else.

With vNext, it seems like we have a few options:

Option 1: DNU Publish

We can use dnu publish to publish the web app as explained in the documentation.

dnu publish -o ../artifacts/webapp --configuration Release --no-source --runtime active

However, the resulting directory is quite big.

• For a vNext (beta 8) web app that just targets dnx451, it's 117MB, or 37MB zipped. This seems to just be a result of so much of ASP.NET now being xcopy-deployable rather than in the GAC.
• For coreclr it's much bigger with the runtime included - around 300MB or 100MB+ zipped.

It does have the upside of guaranteeing that each box will end up running the exact same software with the exact same CLR version.

Since Octopus does delta compression we can probably reduce the actual bandwidth transferred here. Or maybe OctoPack could do some smarts around de-duplication of files (there are many copies of the same files).

Option 2: Just ship the source source

When developers hit F5 to run their code from VS, it isn't compiled - Roslyn interprets it on the fly. At build time, we can just package the project.json and all the source code. Then at deployment time, we can use dnu restore to have each IIS machine go and fetch all the dependencies and compile it.

Downsides:

• Risk that each box gets different dependencies
• Relies on external internet access and a third party source (nuget.org) to be available during deployment, possible security issues there

Option 3: Ship the source, but become our own NuGet server for resolving

Like above, only instead of relying on NuGet.org when resolving dependencies, the Octopus server could resolve them (replacing nuget.org as the feed). I think this can by done by having Octopus replace the NuGet.config or add the feed in project.json. Downside is that it relies on the IIS boxes being able to see Octopus, and security isn't as good as option 1.

Option 1 seems the best, IMHO, but delta-fying will absolutely be required where deploy speed is important or volume is troublesome. For option 2 - having different dependencies all over the place seems like a version of hell, and some environments have no external access available outside of the agreed tentacle connection (public health, for example).

Option 1 would be preferential for me.

Option 1, for me.

What about combining options 3 and 1? Have the source in the package on the octopus server with dependencies single instanced, then at deploy time build the full package to send to the tentacle? This way we don't have to store a bunch of copies of coreclr and the tentacles get complete packages without having to use octopus as a nuget server.

Prefer option 1. Haven't done much with vNext yet - would that require all the CLR files to be in the deployment nupkg?

@rhysgodfrey yes if you target coreclr, no if you target the regular CLR

@PaulStovell It is unclear why CoreCLR/CLR ASPNET5 apps would have special consideration in OD.
Building an ASPNET5 app and publishing to a NuGet package is a core tenant of DNX/DNU. The size of the resulting package should mean little in context of the package containing an ASPNET5 app vs a MVC5-based app.

There is currently an issue with extracting/uncompressing an ASPNET5-based NuGet package due to how Calamari handles multiple nuspec files. This is an issue that effects all packages, not just ASPNET5-based packages although ASPNET-based packages bring it to the forefront.

Option 2 & 3 both have merit outside of ASPNET5 apps and C#; but implemented specifically for ASPNET5 apps, these options leave a lot of gaps as you have already mentioned.

Ultimately, besides fixing the Calamari issue -- OD should have no special considerations besides the core primitives that OD currently provides.

@choudeshell there are a couple of things we need to figure out:

• The building and packaging experience. Octopack as it stands (MSBuild targets) is irrelevant, so we need some way to make it easy for people to make packages.
• Fixing the nuspec issue you mentioned
• Since packages will be bigger, making sure we have great compression will be more important than usual
• Some of our conventions need to change - e.g., supporting appsettings.json instead of app.config for automatic variable replacement

On the whole I agree - ASP.NET 5.0 support in Octopus is going to be a few small changes, not a huge fundamental shift.