How to Deploy Azure Functions

How to Deploy Azure Functions

How your company deploys Azure functions depends on your company’s needs, but these tips should help you decide.

Azure Functions is just a collection of scripts or binaries hosted on the Azure Web App platform. They can be deployed in multiple ways, and no one can tell you which will be the best fit for your organization. That is a broader question that involves more than just technology. But this will hopefully assist you in a decision as to which deployment model best suits your needs.

Azure Functions File System

Before we dive into the setup of those methods a quick explanation of what an Azure Function is, from a File System's perspective. We can check the Function App's content in the Azure Portal by expanding our Function pane to the right to select "View Files."
We can see the very basic setup of an Azure Function. The "definition" is stored in the "function.json" file and the actual code resides in "run.csx" (or whatever extension the language of your choice uses). Plus, each Function has its own directory. Whatever deployment method you will choose, this is the very basic folder s07ucture your Function requires.

Continuous Deployment

Explaining Continuous Deployment (CD) fills books, but here is the quick explanation in the context of Azure Functions. Every time we update our Function, our code, in our local source code repository (e.g. git, Github, Bitbucket) and we commit those changes, a 07igger executes and causes Azure to check the new code and update the Functions accordingly, if needed, automatically.
CD is code that is deployed as soon as the person writing that code feels it is ready to go. The assumption is that you have got your code in a Githubrepository. You can use other Source Con07ol systems, but Github seems to be the most popular around.
To create the link between your Azure Function App and your Github repository, log on to the Azure Portal and navigate to your Function App.


Select the Function App's Platform Features and find the "Deployment Options" link.

The next pane ("Deployments") opens and for our demo Function App this pane should not have any content yet. Only the "Setup" button at the top of the pane should be available to us. This will bring us to the pane where we set up the link between our Source Con07ol repository and Azure. After going through the authentication on Github, and selecting the appropriate repository and branch, we can save the configuration.
The next step should only take about 30 seconds for our demo Function. Azure will clone the repository and copy the code into the correct location on Azure Web App (conveniently abs07acted away). Navigate back to the Function to see that this is now read-only. This is part of "Only one path to Production" and this path is now through our Source Con07ol repository.
Make a change to the code, commit it to your repository and push it online. Wait a few seconds and check your Function. It will reflect the change shortly after your "git push."
In a real workflow, you would have multiple Function Apps that could be configured to be deployed from a "development", a "QA" and a "master" branch on your repository. That way you can deploy code into different environments, and you do not have to commit your code s07aight to master that risks breaking your application.

Azure Functions CLI

Azure Functions comes with its own Command Line Interface (CLI) which is available to install via "npm." This CLI is very handy for local development of Azure Functions as it can run a local Azure Function Application, which is plain awesome. You can write and test your Functions locally. 
However, you can also deploy locally developed Functions from your laptop to Azure. A basic workflow can be found here.

The CLI needs to login to your subscriptions, same as the PowerShell Module or the Azure CLI and you will need to select the correct subscription, if applicable. "func init" will create some boilerplate in the current working directory, and the publish command uploads the code to Azure that will then ex07act it to the correct location.
The CLI does not require a lot of setup, but greatly assists in the development of Functions locally and management of Functions already published on Azure.
I encourage you to check out other options for both the Continuous Deployment integration and the Azure Functions CLI, as these are both very powerful tools when it comes to Azure Functions development.
·         Microsoft Azure vs. Amazon Web Services: Cloud Comparison
·         Free Microsoft Azure Online Training Resources You Need
·         What is Microsoft Azure Stack?


Comments

Post a Comment

Popular posts from this blog

The request has both SAS authentication scheme and 'Bearer' authorization scheme. Only one scheme should be used

Image
While doing testing after doing a POC on Securing Logic App with Azure Active Directory authentication , where I have put logic app behind APIM and before passing the request to logic app, apim does validation of the token.  I was encountered with an error "The request has both SAS authentication scheme and 'Bearer' authorization  scheme.  Only one scheme should be used." Why it happened After validating the token which is part of the header i.e. Authorization, APIM forwards the request as it is to backend. As  Logic app is configured as  back end , it's url already consist of SAS signature plus the request also has Authorization section and this is the problem. By default every request endpoint on a logic app has a Shared Access Signature (SAS) in the endpoint's URL, which follows this format: https://<request-endpoint-URI>sp=<permissions>sv...
Read more

Getting Started with Logic Apps - AS2

Image
What is AS2? Every enterprise requires some kind of product, service or counselling from another enterprises thus there happens a B2B(business to business) communications, some of the communication is unique whereas most of the communications are common for most of the enterprises e.g., Purchase Order. But every enterprise has there own way(format) of sending the messages, leading to difficult management when number of partners increased.  Considering this the Enterprise leaders decided to have some standards/rules defined across the communication leading to B2B protocol standards which provide guidelines for trading partners to follow when conducting business between enterprises. EDI X12, EDIFACT, TRADACOM etc. AS2 stands for Applicability Statement 2 and is a B2B messaging protocol used to transmit Electronic Data Interchange (EDI)/Business documents from one organization to another. So EDI standards define how to format data and AS2 specifies how to securely transport...
Read more

How to Debug and Trace request in Azure APIM - Portal, Postman, RequestBin

Image
Introduction  APIM is a great option to expose API's with out of box features for applying restrictions, preprocessing, postprocessing etc. You can leverage existing API's,  by importing it and it gets added as a new API with all the operations associated with it. And based on the requirements you  apply policies at the stage/level (Inbound,Backend/Outbound) and you are ready to use the API. Before it is shared, we do some testing to make sure everything is working as per the expectation and this is where Debugging and Tracing request becomes important. APIM does provide a way to Trace a call with the help of  Ocp-Apim-Trace http header. So whichever request/call is to be traced, it needs to include this in header  with the value set to true and it has dependency on another header, so that also needs to be passed i.e.  Ocp-Apim-Subscription-Key Note: The api on which Tracing is to applied , it requires the subscription key to be en...
Read more