0
votes

I have an Azure Resource group that contains an Azure Logic App that calls into an Azure Function.

I exported this Resource Group as an ARM template so I can re-import the resources to another Azure Subscription. This works fine, but the problem is, the Azure Function Code (100+ line c# file) is all included on one line of the JSON ARM template file. This makes is really hard to read or modify the Azure Function from the template itself.

Is there an easy way to work around this? Ideally my Azure Function would be in it's own file (run.csx), and the Azure JSON ARM template would just reference that external file.

Here is my JSON blob for the Function Resource in the ARM template. The line that contains run.csx for a key is my concern, how can I make this code more readable and easy for devs to edit?

{
  "apiVersion": "2015-08-01",
  "name": "[concat(parameters('test_site_name'),'\/ProvisionUser')]",
  "type": "Microsoft.Web\/sites\/functions",
  "properties": {
    "config": {
      "bindings": [
        {
          "authLevel": "function",
          "name": "req",
          "type": "httpTrigger",
          "direction": "in"
        },
        {
          "name": "return",
          "direction": "out",
          "type": "http"
        }
      ]
    },
    "files": {
      "run.csx": "LOTS OF C# CODE HERE - LOTS OF C# CODE HERE FROM MY AZURE FUNCTION - LOTS OF C# CODE HERE FROM MY AZURE FUNCTION - LOTS OF C# CODE HERE FROM MY AZURE FUNCTION - LOTS OF C# CODE HERE FROM MY AZURE FUNCTION - LOTS OF C# CODE HERE FROM MY AZURE FUNCTION - LOTS OF C# CODE HERE FROM MY AZURE FUNCTION - ",
      "project.json": "{\r\n  \"frameworks\": {\r\n    \"net46\": {\r\n      \"dependencies\": {\r\n        \"Microsoft.IdentityModel.Clients.ActiveDirectory\": \"3.13.8\",\r\n        \"Newtonsoft.Json\":  \"10.0.2\",\r\n         \"Microsoft.Sdk.CoreAssemblies\" : \"8.2.0.2\"\r\n      }\r\n    }\r\n  }\r\n}"
    }
  }
}
1
It's best to deploy the function files via some cloud hosted zip using the msdeploy provider, e.g. like thisDavid Ebbo
Additionally you can deploy via Source Control references like this example (Function and Logic App) github.com/Azure/azure-quickstart-templates/tree/master/…jeffhollan
Thanks, these look useful, will look into these options.Hampton Terry
Basically I am looking for a flow where: - ARM templates (azure logic app and function) are in Git - dev can open the ARM template in Visual Studio (Azure Resource Group project) - [optional] dev can test Azure Function locally from Visual Studio - dev can deploy to changes to Azure via Visual Studio and test function from Azure (VS Publish) - dev can check in changes to Git Additionally, provide easy way to ship ARM template to customer - currently ARM JSON is uploaded to Azure Blob store which customer can download and applyHampton Terry
Sounds like you are trying to solve stuff which has already been solved using proper CI/CD tools, like VSTS. It's probably better to extract the ARM template, without the contents of the Azure Function, and create a release pipeline in VSTS to deploy the ARM template and the Azure Function afterwards. You're free to try your own approach of course, but probably not a recommended way of deploying software.Jan_V

1 Answers

3
votes

You have some options:

  1. Quick fix to your question: Run your ARM template through some code formatter. You may be in luck if you try copy-paste the template in to a json file in Visual Studio and then CTRL-K,CTRL-D to auto format it. I have not tried this but it may work. You can also cut the code out and format it using any one of a number of online formatting tools or using Visual Studio.

  2. Deploy your functions from a source control system. Treat your infrastructure and code separately. I.e. Create your functions PaaS service from your ARM templates, but then use a CI/CD process to deploy your code and configuration (the functions).

  3. Wrap your code in to an assembly, deploy the assembly to your function host and reference it in your function. This is called an external reference (documentation here) and will limit the amount of code in your function to plumbing, with your logic kept in a separate assembly. You will still need to work out how to deploy the assembly through script or your CI/CD process.

In short, and in line with the comments on your question, you need to support your Azure function development with a little more diligence from a development process perspective. This becomes even more critical if you will have a number of developers working on your functions.

Good luck!