The func command line is great for local development and quick prototypes, but you need managed process based on centralized SCM for team delivery. Function apps can be configured for CI/CD from a Git repo like other App Service apps.
In this lab we’ll deploy a set of chained functions, using CI/CD with GitHub Actions, and test the workflow with some function updates.
You should have your own fork of the lab repo in GitHub (we covered that in the static web apps lab). If not you can sign up for a free GitHub account and create a fork.
If you already have a fork you can update it by clicking Sync Fork in GitHub, or you can just delete it and create another one
We’ll get started with Azure straight away.
📋 Create a Resource Group and a Function App using the consumption plan. Remember you’ll need a Storage Account for the Function App.
Not sure how?</summary>
Nothing much new here:
az group create -n labs-functions-cicd --tags courselabs=azure -l eastus
az storage account create -g labs-functions-cicd --sku Standard_LRS -l eastus -n <sa-name>
az functionapp create -g labs-functions-cicd --runtime dotnet --functions-version 4 --consumption-plan-location eastus --storage-account <sa-name> -n <fn-name>
</details>
Function Apps can be deployed with GitHub Actions. The Azure CLI can connect to your GitHub repo, ask for authentication and then create the pipeline YAML file.
Create a Function App with GitHub deployment - this will open a browser asking for a code which is displayed back in the terminal:
az functionapp deployment github-actions add --branch main --build-path 'labs/functions/cicd/ChainedFunctions' --runtime-version 6 --login-with-github -g labs-functions-cicd --repo '<your-github-fork>' -n <fn-name>
When that completes, check the workflow file in your GitHub fork
GitHub Actions workflows are stored in YAML files in the .github folder in your repo. Browse to the file in GitHub and check the contents. The Function App name may not have been set correctly.
If it looks like this:
env:
AZURE_FUNCTIONAPP_NAME: 'your-app-name' # set this to your function app name on Azure
You need to update it. Click on the edit icon in GitHub (which looks like a pen) and change the name to your actual function app name:
env:
AZURE_FUNCTIONAPP_NAME: '<fn-name>'
Click opn the green Start Commit button and then commit your changes. That will trigger a new build.
Browse to the Actions view and you’ll see your app build and deploy.
Back in the Azure Portal, you will see the Heartbeat function listed (the code is similar to the Scheduled Functions lab):
📋 Create the dependencies the Function needs, and configure the missing setting in the Function app.
Not sure how?</summary>
The Function expects a separate storage account where it will write blobs. You need to create that and set the connection string in the app setting for the Function.
The bindings view for the Function tells you the configuration setting name that you need.
</details>
Verify with the next run of the function that it all works correctly and you see a blob created in your Storage Account.
There are some more functions we can add to the project, which represent a chained workflow - where the output of one function acts as the trigger for the next:
We can add these to the main project and push the changes, which will trigger a build and deploy them:
# add a remote for your fork:
git remote add labs-funcions-cicd <your-github-fork-url>
# pull changes to download the workflow:
git pull labs-funcions-cicd
# copy the new functions into the project folder:
cp labs/functions/cicd/update/*.cs labs/functions/cicd/ChainedFunctions/
# commit and push the changes:
git add labs/functions/cicd/ChainedFunctions/*
git commit -m 'New functions'
git push labs-funcions-cicd main
Watch the build progress in GitHub and then confirm the new functions are running. One will fail
📋 You need to create one more dependency in Azure, and set the configuration for one of the new functions.
Not sure how?</summary>
The new Function writes a message to a Service Bus Queue - you need to create the namespace and the queue, then set the connection string as a Function App setting.
The bindings view for the Function tells you the configuration setting name that you need.
</details>
When you get it all running, you can see how the timer trigger ultimately results in three outputs - the blob, the Table Storage entity and the Service Bus message.
There are some questions around the chaining of functions here. Why doesn’t the Service Bus notification get triggered from the Table Storage write? Then the functions would be guaranteed to run in a known sequence. And if the real goal is the Table Storage entity and the message, can we restructure this to avoid creating a blob?
Stuck? Try suggestions.
Delete the lab RG:
az group delete -y --no-wait -n labs-functions-cicd