Azure Functions custom deployment scripts in C#
Azure Functions utilizes the same “engine” for deployments as Azure App Services, Kudu, by default when you hook up continuous deployment from i.e. GitHub Kudu will handle everything for you and it will just work — you’ll commit your code and shortly after your code is live.
In this post I’ll walk you through the process of overriding the default deployment process triggered when a change occurs in the deployment source.
I’ll use deploying using C# as an example, but basically the sky is the limit here and you could use F# with FAKE, JavaScript with Node, PowerShell or as default plain old batch scripts — basically whatever tool you like.
Why would you do this? Well basically it enables more advanced deployment scenarios like custom paths, private NuGet feeds without committing sensitive information to repository, just to name a few.
Standard deployment
So lets first see what a standard Kudu batch deployment script for Azure Functions could look like below (don’t worry, there will be a summary so you can scroll past it😎)
If you remove the error handling, bootstrapping of tools and initial setup of variables the important line is this one
"%KUDU_SYNC_CMD%" -v 50 -f "%DEPLOYMENT_SOURCE%" -t "%DEPLOYMENT_TARGET%" -n "%NEXT_MANIFEST_PATH%" -p "%PREVIOUS_MANIFEST_PATH%" -i ".git;.hg;.deployment;deploy.cmd"
So what this basically does is syncs the files in the repository with what’s running on the Function App, excluding repository system files and deployment scripts — deleting any files no longer present, adding any new files and overwriting any changes files.
Overriding default script
Overriding the default behavior is actually almost brilliantly simple, add a .deployment file in the root of the repository, the .deployment file can control many aspects of deployment out of the box without needing custom scripts, i.e. overriding Azure Functions Script root in deployment source(i.e. GIT repository), but the setting we’re interested in here is the command setting which lets us set which command should be executed on deployment.
No each time a deployment is triggered either by a commit or initial deploy — it’ll look for a file called deploy.cmd and execute it.
Bootstrapping Cake
So Cake isn’t avail by default on Azure App Services so we need to make sure it’s in-place before we can deploy using C#, we do this in our customdeploy.cmd
What this does is creates a Tool directory, fetches and installs Cake script runner from NuGet and then executes deploy.cake which is our C# deployment script.
Deploying with Cake
So the equivalent of the standard batch deployment script could in Cake look something like below
The #tool directive fetches KuduSync from NuGet (whereas the default fetches from NPM)
The #addin directive fetches the Cake.Kudu addin which is a Cake addin I’ve written which abstracts several things in the Kudu environment in from C# easily accessible via typed objects, properties and methods, i.e. the KuduSync utility.
We could then just have written Kudu.Sync("./src"); and it’ll done the same thing as the batch script, but as a preparation for the future(and because it’s the right way to do it 😉) I utilize the Cake task runner.
Despite that it’s not that much code — and IMHO allot more readable and familiar code for a C# developer vs. a batch script.
And nicer log output is just a nice bonus.
Conclusion
The Cake script in this post is a pretty basic and naive one, when you realize you got the full power of C#, .NET Framework and the hundreds of Cake addins avail it’s really powerful story and I will do follow up posts with more advanced scenarios.
You can read more about Cake at cakebuild.net and there besides Cake’s own documentations — also most addins API’s are documented including Cake.Kudu.
As always feel free to ping me if you have any feedback, praise or questions. You’ll find a complete code from this post at below GitHub repository
azurevoodoo/DeliveringFunctionswithCakeDeploying Azure Functions using C# via Cake scrips github.com