In this post I will walk you through the customization required to get your Azure Web App with both a Website and a Web Job deploying automatically from a remote git repository. We’ll cover both continuously running jobs, as well as scheduled jobs. In both cases zero manual configuration of the job will be required ahead of time.
I will assume you already know how to enable basic Continuous Deployment from your repository via the Azure portal. If not, reference this page in the documentation.
First, lets cover a bit of background information.
Azure Web Apps run on an open source platform named Kudu. Kudu follows a simple set of rules when deploying a Git repository. If Kudu sees that the repository contains a single solution file, with a single web application project in it, then it builds and deploys the website. If it finds anything else, it fails.
This automatic deployment functionality actually works be generating a deployment script with the build and deploy commands in it. You typically don’t see it, but it is actually possible to generate and test this script locally using the Azure CLI with the azure site deploymentscript command.
Creating a Custom Deployment
Ok, so how will we make Kudu deploy our combined Website and WebJob solution if the automatic deployment doesn’t support it? Easy – We’ll provide our own customized deployment script so Kudu doesn’t bother generating its own.
In the root of our repository, we’ll need to add a file named .deployment
This file is the configuration Kudu reads to find its deployment command, and its only two lines:
Next, also in the root of our repository, we need the actual deploy.cmd script. I have prepared one for you, based on the automatically generated Kudu scripts, which installs both a web site and a web job. This will also install dependencies needed to run locally for easy testing (assuming node.js and nuget are in your path).
If you scroll way down past the script, I’ll explain a few of the details.
You’ll only need to make edits to the deployment section of the script, namely steps 1, 2 and 3. Let’s go over what each of the 5 deployment steps does.
1. Restore NuGet packages
This one is pretty self explanatory. All NuGet packages referenced in the solution are restored for our build.
2. Build web site to the temporary path
First we build our website. This could be omitted if we only have a web job. This needs to happen before we build the web job, because msbuild will pave over the whole temporary directory during this build. You’ll need to update the path to the csproj, assuming %DEPLOYMENT_SOURCE% is the root of your repository.
3. Build to web job to a sub folder in the temporary path
Next we build our web job into the correct place in the temporary directory. In addition to updating your project name again, you’ll need to edit the output path to be either “triggered” or “continuous”, depending on your job type. A scheduled job is a triggered job type.
4. Run web job deploy script
This calls of Kudus web job deployment, which does any magic needed to register your web job.
5. Kudu Sync files from temporary to target
This does an intelligent transfer of files from the temporary folder to the live production site. It is “intelligent” because it keeps track of which files in the destination are from the previous deployment, and which ones may have been added by other processes. It leaves non-deployment related files intact.
Testing
Testing that you have configured your script correctly is easy. Simple navigate your command prompt to the root of your repository and run deploy.cmd.
You’ll need to have nuget.exe on your path, as well as node.js. You can grab the exe version of Nuget at https://nuget.org/nuget.exe.
When you run deploy.cmd, it should create a production deployment at ..\artifacts. Check it out and see that your bits are where you expect them. If all is well, just commit to your remote repository and let Azure Continuous Deployment pick up the commit and do its magic.
Scheduled Jobs
Configuring scheduled Web Jobs via the Azure Portal isn’t ideal. It isn’t compatible with continuous deployment, and it isn’t based on any configuration in source control.
Luckily, there is a little known feature of Kudu which allows you to check in a crontab style schedule with your Web Job so that it is automatically scheduled properly with every deployment.
In the root of your Web Job project directory, add a file named settings.job. Be sure to set the project properties on the file to “Copy Always” so it is copied to the output folder during builds.
The contents of this file should look like this:
{"schedule": "0 0 * * * *"}
That is a cron style schedule, but make note that it is six part – not 5 like many linux cron systems. The six parts correspond to seconds, minutes, hours, days, months, years. My example above runs on the 0 second of the 0 minute of every hour/day/month/year – So it is an hourly job.
Note: This form of scheduled job will only run on Standard tier or greater WebApps. Not shared/free.