Continuing from the previous tutorial, we’ll deploy the function we created to Azure. First thing we want to do is replace the storage account used to store the
UserData (the default storage is a good way to start, but we probably want to have a separate account). We do this by defining a new application setting containing the connection string to the storage account, and annotating the function with this setting. It’s a good practice NOT to store credentials and connections strings directly in code, and Azure Functions pushes us to use that best practice by requiring an application setting name. The
local.settings.json file acts as a local storage for application settings, so we’ll take the value we have in
AzureWebJobsStorage and create a new setting called
MyStorageAccount with the same value:
We now go to the Function code and define the name of the setting to use by adding a
StorageAccount annotation to the class, function, or parameter. We’ll add the annotation it at the class level. The new C# file now looks like this:
Hit F5 in VSCode and make sure that everything is still working by invoking the function with some query parameter and checking that the value appears in the local storage emulator.
Now let’s deploy the function to Azure. Open the Azure Functions activity in VSCode and click on the “Deploy to Function App” button:
This will open in the command palette a list of the Function apps that are in the Azure subscriptions we have configured:
For this tutorial we’ll create a new app called “VainoloAzureFunctionsTutorial” instead of reusing an existing one. Follow the prompts to create/use a resource group, and storage account like in the first tutorial. After answer all the questions the deployment process begins:
And after a couple of seconds/minutes the process finishes:
We can go the azure portal to see the new Function App. One important thing to notice is that the code is now read-only in the portal, with a good explanation on why this is the case.
So there is no mixing and matching between editing in the Azure portal and editing on an IDE. Good to know.
Let’s test the function by navigating to its URL… we get an HTTP ERROR 500! That is because we forgot one thing – remember we defined a special value for the storage account used by the Function? We need to update its value in the Azure App application settings with a connection string to a real account in Azure. So let’s navigate back to the Function App in the portal and click on “Application Settings”:
Find the section named “Application settings” (did you know that naming things is one of the biggest problems in software engineering?) and add a new setting named
MyStorageAccount with the connection string to the Azure storage as the setting value:
Let’s go back to the top of the page click “Save”, and try again to execute the function again:
Works! And with the storage explorer we can confirm that the function is using the right storage and writing to it.
Now that we have a local environment ready that is also easy to deploy, we can start investigating all the functionality that is available in Azure Functions. Until then, happy coding!
Next Tutorial: Azure Functions – Part 6: HTTP and Timer Triggers