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 file in the root of the repository, the 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 setting which lets us set which command should be executed on deployment. .deployment .deployment command No each time a deployment is triggered either by a commit or initial deploy — it’ll look for a file called and execute it. deploy.cmd 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 custom deploy.cmd What this does is creates a directory, fetches and installs Cake script runner from NuGet and then executes which is our C# deployment script. Tool deploy.cake Deploying with Cake So the equivalent of the standard batch deployment script could in Cake look something like below The directive fetches KuduSync from NuGet (whereas the default fetches from NPM) #tool The directive fetches the 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. #addin Cake.Kudu We could then just have written 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. Kudu.Sync("./src"); 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 and there besides Cake’s own documentations — also most addins API’s are documented including . cakebuild.net 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 github.com azurevoodoo/DeliveringFunctionswithCake Deploying Azure Functions using C# via Cake scrips
