It is hard to overstate how excited I am about the wave of changes coming in ASP.NET Core 1 and the dotnet CLI. While the programming languages and API's don't change dramatically, the work going on under the hood, around how the runtime is distributed, the move to being command-line first, and making it cross platform, is just wonderful. This is a great time to be a .NET developer.
In this post, I want to explain some of the major changes that I think impact build and deployment pipelines for developers, and show how it will work with ASP.NET Core 1 RC1 and RC2. My plan was to put this all into a free ebook on ASP.NET Core 1 build and deployment, but given the move to dotnet CLI and delays to the release date, I think it's time for an update while the book waits for RC2 to be released.
Before we get into how to build & deploy, there's a major change I want to talk about.
Publishing applications is going to be standardized!
When you ship an ASP.NET app to production, there are files it needs - DLL's, config files, CSS/JS, images, and so on. Likewise, when a Windows Service or console app runs in production, there are files it needs - executables, DLL's, config files, etc.
Until now, there's never ever been a consistent way to "publish" all of those .NET applications. ASP.NET projects had a complex command line incantation that would "publish" a website, but that didn't work for a Windows Service. For a Windows Service, you'd probably just zip the bin\release directory. That's why for the last four years we've relied on OctoPack to bridge all of this - OctoPack's whole purpose is to look at your project, and try to figure out what is supposed to be published.
I lamented this lack of a standard way to publish and package all .NET applications in my post on Wanted: a universal package format for .NET.
The great news is that when the dotnet CLI ships, there's finally going to be a standard way to publish these applications. They are only published to a folder, so an extra step is needed to package the application, but at least this is very close.
With the new dotnet tooling, you can dotnet publish a web app, or a console app, or presumably a Windows Service or eventually WPF app (assuming all of these platforms are eventually ported), and it will produce a folder with the files needed for the application to run.
This has another impact: OctoPack will be a relic of the past. A combination of dotnet publish and then zipping the output will be the replacement.
What a build and deployment process will look like
The diagram below gives an overview of the building blocks of a build & deployment pipeline with Octopus will look like, in this brave new world:
An example
Here's an example of what that looks like with ASP.NET 5 RC1:
dnu restore source/MyApp.Web source/MyApp.Tests
dnu publish source/MyApp.Web --runtime active --out published-app --no-source
octo pack --id MyApp.Web --version 1.0.0 --basePath published-app --format zip
octo push --package MyApp.Web.1.0.0.zip --server http://octopus --apikey API-1234567
octo create-release --project MyApp --version 1.0.0 --packageversion 1.0.0 --server http://octopus --apikey API-1234567
With TeamCity
The TeamCity team are working on a new plugin that wraps the DNU/DNX and dotnet commands. Rather than writing scripts, you can use this plugin to perform the equivalent of the dnu commands above:
This week we also released an update for the Octopus TeamCity plugin that wraps octo.exe push. You can use it to create ZIP files on the fly and push them to Octopus:
Once you have published the application, packaged it, and pushed it to Octopus, it's business as usual. We do have a new Octopus JSON configuration feature to take advantage of the new appsettings.json file format, but other than that, not much has needed to change within Octopus to support ASP.NET Core 1.
Summary
ASP.NET Core 1 makes publishing a first class feature of the platform. This eliminates the need for OctoPack, and will eventually standardize the process of publishing applications ready for deployment. If you're using TeamCity, there's a new plugin to invoke those commands, and we can expect other build servers to get similar commands in future. All that's left is to ZIP the published folder, push it to Octopus, and then use Octopus to deploy it.
Welcome to the brave new world!
