Architect, Technologist, and gamer.

Director Engineering , Red Ventures

Continuous Delivery to Azure Websites with git using custom deployment script

Continuous Delivery to Azure Websites with git using custom deployment script

With Azure Websites, setting up Continuous Delivery (CD) of your code as it's committed is incredibly easy to set up. 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 own customization for a successful CD deployment. The deployment script is very much like an MSBuild or grunt.js script in that you are defining a series of tasks that need to happen in order 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 . 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 just 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 tools' 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 as well as the solution file that is needed for the nuget package restore. Here is an excerpt from that generated script showing those steps in action:

For the Node application, you'll see that all of the MSBuild an Nuget specifics are omitted. Instead replaced with Node specifics like preforming 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 that I need to install prior to build. 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 yourself, or use a great 3rd party service like MyGet to get the job done. Once that's up, you'll now need to tell Nuget restore 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'm going to 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 that will be used to do the restore. It's the configuration file specifically that 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 place, I now have my enterprise Asp.Net app successfully connected to my Azure Website for continuous delivery! If your looking for even more customization and integration with your alm tools, then you may want to consider using a dedicated build server like TeamCity. I'm planning a followup to this post on setting up CD with Azure using TeamCity in the near future.

Streamline your TFS to Git migration with Gitflow

Streamline your TFS to Git migration with Gitflow

Migrate an existing project from TFS to Git with changeset history intact

Migrate an existing project from TFS to Git with changeset history intact