Function Apps are stored using a basic file structure, as shown previously. Given this, they can be deployed through mechanisms that support a file structure in a similar way to Web Apps, including the use of continuous integration and continuous deployment.
Deployment options are available in the App Service settings.
Deployment credentials allows the setting of the username and password for deployment via FTP or Git. The FTP endpoint for the Function App can be found in Properties of the App Service.
Deployment options provides access in order to set up deployment from a number of sources.
For example, to set up Github as the deployment source, we would choose GitHub from the list. For most of the sources, we need to authorize access to the specific account. Once this has been provided, the source can be configured.
If Visual Studio Team Services is chosen as the deployment, it is not necessary to authorize access if the instance of Visual Studio Team Services has already been configured within the Azure subscription.
When developing functions, as with all development, it is important to ensure that it can be easily tested and that it is then fully tested before production deployment.
There are many ways to test a function, some of which have been shown previously through the chapter, but it is worth reviewing them here:
- Use the log stream to check the status of incoming messages, compilation warnings, and errors.
- A Timer trigger can be used to trigger other functions by integrating outputs that form the input for the trigger to be tested. For example, a Timer trigger could place a message on a Service Bus queue that has another trigger using the queue as input. This technique works for any functions that can act as a triggered event, and for other functions that need to read input from sources that require a triggered event such as reading documents out of DocumentDB.
- For HTTP triggers and WebHooks, Postman (https://www.getpostman.com/) can be used to perform any HTTP operation, such as GET, POST, or DELETE, against the function.
- For HTTP triggers, a browser can be used against the function endpoint to perform a GET operation. The function endpoint is available on the code page under Function Url.
- A storage-based trigger function can be tested using any tool that supports interacting with Azure storage such as Visual Studio or Microsoft Azure Storage Explorer.
- For the majority of triggers, the Run dialog on the function development page can be used to provide input in any text-based format.
Using these approaches either individually or together there can be confidence that the function will operate as expected.
Function Apps can exist in the context of a current App Service Plan or App Service Environment, or it can be serverless and used via a Consumption Service Plan where the user needs to have no knowledge of or responsibility for the underlying infrastructure.
When used in an App Service Plan, the Function App can be scaled in the same way as any other service within an App Service plan by changing the plan settings.
- Scale up: The plan can be moved to a different pricing tier that provides machines with greater capability
- Scale out: The plan can have the number of instances of machines increased either manually, due to CPU percentage load or based on a schedule
When the Function App is in a Consumption Service Plan, it is scaled based on need. The unit of scale is the Function App itself, and scaling is automatic and adds new instances as required. When the instances are no longer required based on the demand, they are removed automatically.
Another important feature of Function Apps is the ability to monitor the executions of each function. Monitoring is available in each function via the Monitor tab.
You can look at the invocation logs to see the specific messages and the number of successful or failed messages, and drill in to the message content.
The live event stream displays a graphical representation of the performance of the specific function including number of executions started and completed each second, number of failed executions per second, and the average execution time.
Using the monitoring is not only a way of getting an understanding of how exactly a function is performing, but also a good way of checking on invocations of functions and if errors are detected across your application.
