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.

@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.