Azure Functions - Prepare for continuous delivery

As part of our research of using Feature Flags with VSTS extensions, we exposed our secure VSTS token based solution, implemented with Azure Functions to:

• Generate a hash Key by server-side
• To call the REST API of LaunchDarkly

We’re dogfooding our own research outcome! We’re implementing the Azure Functions, backed by a CI/CD pipeline.

In this new series of blog posts, we’ll discuss the following:

• How to develop and debug an Azure Function
• How to test an Azure Function with Postman
• How to use an ARM Template to define and deploy the Azure resources
• A walkthrough of a complete CI/CD pipeline to configure and deploy the Azure Functions

Let’s start with the development, debugging, and testing of our Azure Functions.

Prepare the development environment

There are several different tools and approaches to code Azure functions. Visual Studio 2017 15.3 offers the best development experience , or higher. It’s useful for:

• Developers who are familiar with Visual Studio
• IntelliSense and compilation features available with Azure function development
• Easily adding Unit Test project
• Using precompiled Azure Functions to avoid dynamic compilation
  See Precompiled Azure Functions Revisited for details.

Requirement: Install the “Azure development” workload

Create the project

• Create a new project, based on the Azure functions template.
  
• The generated project contains only the host.json and local.settings.json files.
• Add a new item and select Azure Function.
  
• When prompted by the wizard, select Function as the Azure Function type, and define the name for the C# class.
  

Inspect the generated project

• Generated project:
  
• For readability, we renamed the Function.cs to match the name of the Azure Function And write the code of our Azure Function.
  

We did the same operation for the code of our 2 Azure Functions (see the 2 Azure Functions details in building-vsts-extensions-with-feature-flags-part-2 and building-vsts-extensions-with-feature-flags-part-3 ) and move these 2 class in new folder “AzureFunctions”

A few observations. There is:

• No sub folder for the Azure Function (yet)
• No .json configuration file for the Azure Function (yet)
• A new decorator describing the name of the Azure Function [1]
• A new parameter in the code of the Function Azure [2]
• A new nuget Microsoft.Net.sdk.function package referenced in the project

We have also added to our project other classes for Helpers methods, and another to centralize all methods of LaunchDarkly calls.

After all developments, the final project structure looks like this:

Build the project

When you build the project, you’ll create the structure for the Azure Function App.

• There’s one folder by Azure Function
• There’s a function.json file describing the method properties that contain the start point for the Azure Function method.
  

Note: It’s the Microsoft.Net.sdk.function package that generates an Azure Function App folder from a classical class library project.

Test your Azure Function locally

We use a local simulator to host the function. It’s part of the Azure Development tools and integrated with the Visual Studio Azure Function Core tools.

• To launch this simulator, click to the debug button of your solution.
  
• The local simulator launches.
  
• The local URL for the Azure Function is displayed in the simulator console.

Now that the simulator hosts our Azure Function, we can switch to the Postman tool. It’s powerful tool to test HTTP REST APIs, including our Azure Function.

• Setup the local URL of your Azure Function and its parameters.
  
• Set a breakpoint in the code of our Azure Function
• Using Postman, send the query.
  
• Observe how the simulator shows debug info, for example parameters, query type, and return code.
  
• If you have set a breakpoint, the simulator will break and allow you to debug.
  
• We'll cover the Postman tool in detail in an upcoming post.
• If your Azure Function uses the appSettings keys, you can set them in local.settings.json file for a local use.
  

Unit Tests

Now that we have a classic. Net project with our Azure Function, we can add a Unit Tests project to our solution to test our Azure Functions.

• Add a Unit Tests project to your Azure Function solution and Add the Azure Function project as Reference into this unit test project
  
• We write 3 unit tests for tests business methods
• Here’s an code of one of our unit test methods.
  
• When we compile the solution or the first time, we’ll get the error: Metadata file ‘C:\repo\AzureFunction\bin\Debug\net461\FunctionApp.dll’ could not be found

As Laurent Bugnion explains in Running unit tests we Azure Functions in Visual Studio 2017, the solution is to update the Microsoft.Net.sdk.function package with the latest version (1.0.2).

• When we re-compile the solution, the unit tests build with no error.
• We can now run all tests using the Visual Studio Tests Explorer.

At this point we introduced the development and testing of our Azure Functions locally. We intentionally have not talked about publishing your Azure Function App directly from Visual Studio 2017. Instead we’ll create and use a CI/CD pipeline to build and release your Azure Function.

Coming up next

In the next part of this blog post series we will continue with artifacts for our Azure Functions DevOps pipeline and will talk about the provisioning and the configuration of the Azure infrastructure with an ARM template.

THANK YOU REVIEWERS: Edward Fry, Giulio Vian, Hamid Shahid, Tiago Pascoal

Comments

• Anonymous
  October 27, 2017
  This is a great article and has been very useful to me and the team. It would be helpful to add links to the next article in the series and links back to this one from there.