With Azure Websites, setting up Continuous Delivery (CD) of your code as it's committed is incredibly easy. In most cases, it's as simple as clicking the "Set up deployment from source control" link on the website dashboard, selecting the source (GitHub, Bitbucket, custom), and then letting Azure go to work behind the scenes building (if necessary), testing, and deploying your code. For everyone else outside of the majority, there are custom deployment scripts. Deployment scripts in Azure are powered by a Microsoft-run open-source project called kudu. Kudu is the engine that powers all git deployments in Azure and is also what will allow you to make your customization for a successful CD deployment. The deployment script is very much like an MSBuild or grunt.js script in that you define a series of tasks that need to happen for your project to be successfully built, tested, and deployed in the websites environment. And best of all, with the Azure CLI tools installed, you're only one command away from getting started.
If you don't already have the Azure cross-platform CLI tools, then pause here and get those configured http://www.windowsazure.com/en-us/documentation/articles/xplat-cli/ . I recommend the npm installation method.
Generate your script
For this example, my project source code is located in a sub-directory called
src. If I were to connect my repo to Azure without using a deployment script, then Azure would not know how to find my project files, and the deployment would fail. To prevent that, I'll use the CLI tool's
site deploymentscript command to tell kudu exactly where to find my project, overriding the default behavior.
For the Asp.Net web application, I'm passing in the web project to be deployed and the solution file needed for the NuGet package restore. Here is an excerpt from that generated script showing those steps in action:
You'll see that all of the MSBuild and Nuget specifics are omitted for the Node application. Replaced with Node specifics like performing an
npm install of your required modules during deployment.
Private NuGet Feed
Now I want to take that one step further. For most of my projects, I have several internal Nuget packages I need to install before building. Like most businesses, I have internal libraries that my application depends on, which are not in the public domain. NuGet makes this possible by allowing you to provide custom feeds secured with basic authentication. You could host the feed or use an excellent 3rd party service like MyGet to get the job done. Once that's up, you'll need to tell Nuget how to access it. In this case, I'm using Azure CD, which knows nothing about my feed or the credentials I need to supply to it. So to accomplish that, I'll need to make a few changes to my repository.
First, I will add my own Nuget.exe and Nuget.config to my repository in the tools/nuget/ directory. This will give me direct control of the version and configuration used to do the restore. The configuration file will allow me to pass in both my custom feed URL and its credentials.
Note that committing your nuget.config file is not recommended for public repositories since your nuget feed credentials would become public as well.
Finally, I'll swap out the default Nuget.exe reference in my kudu script with my own Nuget.exe and Nuget.config file.
I've replaced the
"%NUGET_EXE%" variable with my own
"%DEPLOYMENT_SOURCE%\tools\nuget\nuget.exe" and then added the
-ConfigFile argument to force the use of my custom configuration. I could probably get away with keeping the default Nuget.exe reference, but to avoid any compatibility issues, I feel it's safer to supply my own.
With those modifications in place, I now have my enterprise Asp.Net app successfully connected to my Azure Website for continuous delivery! If you're looking for even more customization and integration with your ALM tools, you may consider using a dedicated build server like TeamCity. I'm planning a follow-up to this post on setting up CD with Azure using TeamCity in the near future.