Getting Started With NuGet 5.8 (Jon Douglas) - A very interesting post about the new features included in NuGet, and since it is the first one supporting .Net 5, some advice for a better experience.
What is a Developer Game Jam? (Coding Blocks) - Interesting episode about Game Jam... I barely know that universe. Yes, I said universe because it is a completely different world or better another dimension. There are tons of events and participants but you may never hear of that. It's very interesting.
Every Monday, I share my "reading notes". Those are a curated list of all the articles, blog posts, podcast episodes, and books that catch my interest during the week and that I found interesting. It's a mix of the actuality and what I consumed.
You think you may have interesting content, share it!
Creating a .NET Core Global Tool (John Smith) - Cool project. It gave me ideas of little things I would like to have available...
How to Docker with .NET: Getting Started (Dave Brock) - A truly beginner tutorial. If you know about Docker but never did really play with it, here is your chance. First post of a trilogy that definitely worth our time.
Learn Node.js with this series of short videos for beginners (Microsoft) - An amazing series of tiny videos. I started myself and already learned so much! Perfect bite-size to watch in a break, or to find THE topic/ answer you are looking for.
Great book. I wasn't sure first but someone recommended it and since, I like her first book and thought why not! I was not disappointed. I like this journey through interviews. Each person (yes real person, not characters), is great; full of emotions, victory, fails... like us, well me at least.
Every Monday, I share my "reading notes". Those are a curated list of all the articles, blog posts, podcast episodes, and books that catch my interest during the week and that I found interesting. It's a mix of the actuality and what I consumed.
You think you may have interesting content, share it!
6 Tools I use for Web Development (Jakob Klamser) - A nice list of great tools. I'm surprised to read that notion would be more flexible then OneNote, I heard a lot of good from it but never tried it.
Every beginning of weekend, I will share a recap of the week and at the same time a summary of my streams. Those videos are at least two hour longs, so I thought a short summary to know if topic interest you could be useful. Watch only the summary or relax and enjoy the longer version that up to you!
Coding Python: Deploy Django and Postgres Apps to Azure with VS Code - c5m.ca/aaa-ep25
Stream 119 - How easy can we make the deployment of TinyBlazorAdmin - c5m.ca/stream-ep119
Stream120 - Celebrating 500 followers and working on the Chat bot - c5m.ca/stream-ep120
211: Failure To Launch (Merge Conflict) - Interesting conversation about when it's time to stop adding features and deploy. Finding a comfortable point could be difficult sometime.
Remote Debugging .NET Containers (Karol Deland) - A nice tutorial that explains clearly first the difference between remote and local debugging and then explains how to do it.
Screen Sharing with an Ultrawide Monitor (Kenny Lowe) - Really interesting post.As I think about getting a new screen and heard bad experiences sharing ultrawide screens this look like a nice solution.
An interesting book that shares the best practices about making videos today. How to plan, record, edit... What to do and not do. A quick, direct to the point and complete tutorial to get started. This book was done like today's videos.
Every Monday, I share my "reading notes". Those are a curated list of all the articles, blog posts, podcast episodes, and books that catch my interest during the week and that I found interesting.
It's a mix of the actuality and what I consumed. As you will quickly see This week is heavily tinted by the Microsoft Build event. I still have tons of videos to watch since I was was busy monitoring the chat during most of the performances.
You think you may have interesting content, share it!
Chocolatey with Rob Reynolds (.NET Rocks!) - Awesome episode talking about all the good and the great of Chocolatey that awesome package manager.
A path to technical leadership with Keavy McMinn (Hanselminutes with Scott Hanselman) - Because the most interesting path are more then often not the straight one... Great talk about the choice we make in our lives...
Every Monday, I share my "reading notes". Those are a curated list of all the articles, blog posts, podcast episodes, and books that catch my interest during the week and that I found interesting.
It's a mix of the actuality and what I consumed. You think you may have interesting content, share it!
070: Securing DevOps in the Cloud (CloudSkills.fm) - Great episode talking about security yes but also best practices and to change mindsets. Love it.
Running a successful dev shop with Martin Gratzer (Software Engineering Unlocked) - This show is one of my new favorites. Always interesting and very dynamic. This time it was about the hard reality of "dev shop". Very interesting, so true!
The Overreaction Paradox (Developer Tea) - I never thought about it that way... But it's so true. Are we celebrating the wrong things?
197: I Need a Website (Merge Conflict) - They got me 50% of the time... I think they are talking to me: 'Frank we are ....'. Nice episode sharing some dreams about a perfect tool (aka website) for apps developers.
Most solutions, if not all, are composed of multiple parts: backend, frontend, services, APIs, etc. Because all parts could have a different life-cycle it's important to be able to deploy them individually. However, sometimes we would like to deploy everything at once. It's exactly the scenario I had in a project I'm working on where with backend and one frontend.
In this post, I will explain how I use nested Azure Resource Manager (ARM) templates and conditions to let the user decide if he wants to deploy only the backend or the backend with a frontend of his choice. All the code will be available in GitHub and if you prefer, a video version is available below. (This post is also available in French)
The Context
The project used in this post my open-source budget-friendly Azure URL Shortener. Like mentioned previously the project is composed of two parts. The backend leverage Microsoft serverless Azure Functions, it a perfect match in this case because it will only run when someone clicks a link. The second part is a frontend, and it's totally optional. Because the Azure Functions are HTTP triggers they act as an API, therefore, they can be called from anything able to do an HTTP call. Both are very easily deployable using an ARM template by a PowerShell or CLI command or by a one-click button directly from GitHub.
The Goal
At the end of this post, we will be able from one-click to deploy just the Azure Functions or to deploy them with a frontend of our choice (I only have one right now, but more will come). To do this, we will modify the "backend" ARM template using condition and nest the ARM template responsible for the frontend deployment.
The ARM templates are available here in there [initial](https://github.com/FBoucher/AzUrlShortener/tree/master/tutorials/optional-arm/before) and [final](https://github.com/FBoucher/AzUrlShortener/tree/master/tutorials/optional-arm/before/after) versions.
Adding New Inputs
We will nest the ARM templates, this means that our backend template (azureDeploy.json) will call the frontend template (adminBlazorWebsite-deployAzure.json). Therefore we need to add all the required information to azureDeploy.json to make sure it's able to deploy adminBlazorWebsite-deployAzure.json successfully. Looking at the parameter required for the second template, we only two need values AdminEMail and AdminPassword. All the other can be generated or we already have them.
We will need also another parameter the will act as our selection option. So let's add a parameter named frontend and allowed only two values: none and adminBlazorWebsite. If the value is none we only deploy the Azure Function. When the value is adminBlazorWebsite we will deploy the Azure Function, of course, but we will also deploy an admin website to go with it.
Following the best practices, we add clear detail and add those three parameters in the parameters section of the ARM template
"frontend": {
"type": "string",
"allowedValues": [
"none",
"adminBlazorWebsite"
],
"defaultValue": "adminBlazorWebsite",
"metadata": {
"description": "Select the frontend that will be deploy. Select 'none', if you don't want any. Frontend available: adminBlazorWebsite, none. "
}
},
"frontend-AdminEMail": {
"type": "string",
"defaultValue": "",
"metadata": {
"description": "(Required only if frontend = adminBlazorWebsite) The EMail use to connect into the admin Blazor Website."
}
},
"frontend-AdminPassword": {
"type": "securestring",
"defaultValue": "",
"metadata": {
"description": "(Required only if frontend = adminBlazorWebsite) Password use to connect into the admin Blazor Website."
}
}
Nested Templates
Let's assume for now that we always deploy the website when we deploy the Azure Function, to keep things simple. What we need now is to used nested ARM template, and that when you deploy an ARM template from inside another ARM template. This is done with a Microsoft.Resources/deployments node. Let's look at the code:
If we examine this node, we have the classic: name, type, dependsOn, resourceGroup, apiVersion. Here We really want the Azure Functions to be fully deployed so we need the FunctionApp to be created AND the GitHub sync to be complete, this is why there is also a dependency on Microsoft.Web/sites/sourcecontrols.
In properties we will pass the mode as Incremental as it will leave unchanged resources that exist in the resource group but aren't specified in the template.
The second property is templateLink. This is really important as it's the URL to the other ARM template. That URI must not be a local file or a file that is only available on your local network. You must provide a URI value that downloadable as HTTP or HTTPS. In this case, it's a variable that contains the GitHub URL where the template is available.
Finally, we have the parameters, and this is how we pass the values to the second template. Let's skip those where I just pass the parameter value from the caller to the called, and focus on basename, AzureFunctionUrlListUrl, and AzureFunctionUrlShortenerUrl.
For basename I just add a prefix to the parameter basename received, this way the resource names will be different but we can still see the "connection". That's purely optional, you could have added this value in a parameter to azureDeploy.json, I prefer keeping the parameters a minimum as possible as I think it simplifies the deployment for the users.
Finally for AzureFunctionUrlListUrl, and AzureFunctionUrlShortenerUrl I needed to retrieve the URL of the Azure Function with the security token because they are secured. I do that by concatenating different parts.
Component
Value
Beginning of the URL
'https://'
Reference the Function App, return the value of hostname
Now that the second ARM template can be deployed, let's add a condition so it gets, indeed, deploy only when we desire. To do this it's very simple, we need to add a property condition.
In this case, is the value of the parameter is different then none, the nested template will be deployed. When a condition end-up being "false", the entire resource will be ignored during the deployment. How simple or complex are your conditions... that's your choice!
Bring your own machine to Visual Studio Online | Visual Studio Blog (Allison) - Fantastic news! Before it was possible to access a powerful developer environment from our poor local devices. Now we can also access our own powerful machine from elsewhere! That's very very nice!
195: The Hanselman Machine Learning Model (Merge Conflict) - Great episode where Frank and James discuss how James could build a sentiment analysis of Hanselman tweets, is it possible or not and what would be the cost (effort, and money).
GitHub Actions with Enrico Campidoglio (.NET Rocks!) - I think it's my first .Net Show since the Pandemie. Well with was a create show that dig deeper in the GitHub Action. Loved it.
068: How to Build Your Personal Brand (CloudSkills.fm) - I really liked this episode as I did "created" my personal brand (without really realizing it ) a few years ago.
455: How to Create Great Relationships, with Colleen Bordeaux (Coaching for Leaders) - Interesting discussion with the author of the book: Am I Doing This Right?: A Philosophical Guide to Life in the Age of Overwhelm, that is now in my to read list/
I don't know for you but I share links/ URLs very often. And a lot of time it's from videos, so it needs to be short and easy to remember. Something like https://c5m.ca/project is better than a random string (aka. GUID). And this is how I started a project to build a URL Shortener. I wanted to be budget-friendly, easy to deploy and customizable.
In this post, I will share how I build it, how you can use it, and how you can help!
How I build it, with the community
This tool was build during live streams coding sessions on Twitch (all videos are in available in my YouTube archive). It's composed of two parts: a Serverless backend leveraging the Azure Function & Azure Storage, and a frontend of your choice.
The backend is composed of a few Azure Functions that act as an on-demand HTTP API. They only consume when they are called. They are in .Net Core, C# to be specific. When publishing this post, there are four functions:
UrlShortener: To create a short URL.
UrlRedirect: That's the one called when a short link is used. An Azure Function Proxy is forwarding all call to the root.
UrlClickStats: Return the statistic for a specific URL.
UrlList: Return the list of all URLs created.
All the information like long url, short url, click count are save in an Azure Storage Table.
And that's it. Super light, very cost-efficient. IF you are curious about the price I'll but references in the footnotes
The frontend could be anything that can make HTTP requests. Right now in the project, I explain how to use a tool call Postman, there is also a very simple interface done that you can easily deploy.
This simple interface is of course protected and gives you the options to see all URLs and create new ones.
How YOU can use it
All the code is available into GitHub, and it's deployable with a one-click button!
This will deploy the backend in your Azure subscription in a few minutes. If you don't own an Azure subscription already, you can create your free Azure account today.
Then you will probably want an interface to create your precious URLs. Once more in the GitHub repository, there is a List of available Admin interfaces and ready to be used. The Admin Blazor Website is currently the most friendly and can also be deployed in one-click.
How You can help and participate
Right now, there is really only one interface (and some instructions on how to use Postman to do the HTTP calls). But AzUrlShortener is an open-source project, meaning you can participate. Here some suggestions:
Build a new interface (in the language of your choice)
Improve current interface(s) with
logos
designs
Better UI 🙂
Register bugs in GitHub
Make feature request
Help with documentation/ translation
What's Next
Definitely come see the GitHub repo https://github.com/FBoucher/AzUrlShortener, click those deploy buttons. On my side, I will continue to add more features and make it better. See you there!
Every Monday, I share my "reading notes". Those are the articles, blog posts, podcast episodes, and books that catch my interest during the week and that I found interesting.
It's a mix of the actuality and what I consumed. Enjoy!
Suggestion of the week
Approval Workflows With GitHub Actions (Aaron Powell) - Wow! That's a very clever and impressive way to have step flow in GitHub. All the details are in the post if you would like to create your own.
GitHub with Azure DevOps | Premier Developer (GitHub with Azure DevOps) - Very interesting post that explains al the benefits of using this mixt, and why an enterprise would be interested to do that.
193: UI Is Messy (Merge Conflict) - I, once more, had a nice moment listening to that discussion/ argumentation about different patterns pros and cons.
Every Monday, I share my reading notes. Those are the articles, blog posts, podcast episodes, and books that catch my interest during the week and that I found interesting. It's a mix of the actuality and what I consumed.
How to Prepare for a Successful Cloud Migration (Aaron Woods) - This post list the questions we should ask ourselves before migrating. This will definitely help to reduce the bumps of a migration.
Every week, I publish my reading notes. Those are the articles, blog posts, podcast episodes, and books that catch my interest and that I found interesting. It's a mix of the actuality and what I was looking for. This one is the last of 2019!
Upgrading the Blazor HTML Table with FlexGrid ( Alvaro Rivoir) - This is a great tutorial that explains very clearly step by step how to replace the grid in the default Asp.Net Core project.
Miscellaneous
Advice to my 20 year old self (Scott Hanselman) - An Interesting post. But to be honest, the more I think about it the less I would spoil things. So as good or bad as it sounds, my advice would probably just be something like thrust yourself, you'll be fine.
You hear about that new GitHub Actions. Or maybe you didn't but would like to add a continuous integration, continuous deployment (CI-CD) to your web application. In this post, I will show you how to add a CI-CD to deploy automatically to Azure using the GitHub Actions.
What are GitHub Actions
GitHub Actions are automated workflows to do things. One of these could be a CI-CD. Using a workflow you could decide to compile and execute some unit tests at every push or pull request (PR). Another workflow could be that you deploy that application.
In this article, I will deploy a .Net Core application in Azure. However, you can use any languages you would like and deploy anywhere you like... I just needed to pick one :)
Now, let's get started.
Step 1 - The Code.
We need some code in a GitHub repo. Create a GitHub repo, clone it locally. And your app in it. I created mine with dotnet new blazorserver -n cloud5minsdemo -o src. Then commit and push.
Step 2 - Define the workflow
We got the code, now it's time to define our workflow. I will be providing all the code snippets required for the scenario cover in this post, but there is tons of template ready to be used available directly from your GitHub repository! Let's have a look. From your repository click on the Action tab, and voila!
When I wrote this post, a lot of available templates assumed the Azure resources already existed and you and adding a CI-CD to the mixt to automated your deployment. It's great but in my case, I was building a brand new web site so those didn't fit my needs. This is why I created my own template. The workflow I created was inspired by Azure/webapps-deploy. And there a lot of information also available on Deploy to App Service using GitHub Actions.
Let's add our template to our solution. GitHub will look in the folder .github/workflows/ from the root of the repository. Then create a file with the extension .yml
Here the code for my dotnet.yml, as any YAML file the secret is in the indentation as it is whitespace sensitive:
on: [push,pull_request]
env:
AZURE_WEBAPP_NAME: cloud5minsdemo # set this to your application's name
AZURE_GROUP_NAME: cloud5mins2
jobs:
build-and-deploy:
runs-on: ubuntu-latest
steps:
# checkout the repo
- uses: actions/checkout@master
- name: Setup .NET Core
uses: actions/setup-dotnet@v1
with:
dotnet-version: 3.0.101
# dotnet build and publish
- name: Build with dotnet
run: dotnet build ./src --configuration Release
- name: dotnet publish
run: |
dotnet publish ./src -c Release -o myapp
- uses: azure/login@v1
with:
creds: ${{ secrets.AZURE_CREDENTIALS }}
- run: |
az group create -n ${{ env.AZURE_GROUP_NAME }} -l eastus
az group deployment create -n ghaction -g ${{ env.AZURE_GROUP_NAME }} --template-file deployment/azuredepoy.json
# deploy web app using Azure credentials
- name: 'Azure webapp deploy'
uses: azure/webapps-deploy@v1
with:
app-name: ${{ env.AZURE_WEBAPP_NAME }}
package: './myapp'
# Azure logout
- name: logout
run: |
az logout
The Agent
There is a lot in there let's start by the first line. The on: is to define the trigger, in this case, the workflow will be trigger at every push or PR.
The env: is where you can declare variables. It's totally optional, but I think it will help then templates are more complex or simply to reuse them easily.
Then comes the jobs: definition. In this case, we will use the latest version of Ubuntu as our build agent. Of course, in a production environment, you should be more specify and select the OS that matches your needs. This job will have multiples steps defined in the, you guess it, steps: section/
We specify a branch to work with and set up our agent by:
And it would be a better idea to set the version as an environment variable to be able to change it quickly.
The next two instructions are really .Net Core focus as they will build and package the application into a folder myapp. Of course, in the "section" you could execute some unit test or any other validation that you may find useful.
To have our GitHub Action to be able to create resources and deploy the code it needs to have access. The azure/login@v1 will let the Action login, using a Service Principal. In other words, we will create an authentication in the Azure Active Directory, with enough permission to do what we need.
This will create a Service Principal named "c5m-Frankdemo" with the role "contributor" on the subscription specified. The role contributor can do mostly anything except granting permission.
Because no resources already existed the GitHub Action will require more permission. If you create the Resource Group outside of the CI-CD, you could limit the access only to this specific resource group. Using this command instead:
The Azure CLI command will return a JSON. We will copy-paste this JSON into a GitHub secret. GitHub secrets encrypted secrets and allow you to store sensitive information, such as access tokens, in your repository. To access them go in the Settings of the repository and select Secrets from the left menu.
Click the Add a new secret button, and type AZURE_CREDENTIALS as the name. It could be anything, as long as you use that value in the YAML file describing the workflow. Put the JSON including the curly brackets in the Value textbox and click the save button.
Provisioning the Azure Resources
Now that the workflow has access we could execute some Azure CLI commands, but let's see what missing:
- run: |
az group create -n ${{ env.AZURE_GROUP_NAME }} -l eastus
az group deployment create -n ghaction -g ${{ env.AZURE_GROUP_NAME }} --template-file deployment/azuredepoy.json --parameters myWebAppName=${{ env.AZURE_WEBAPP_NAME }}
The first command will create an Azure Resource Group, where all the resources will be created. The second one will deploy the website using an Azure Resource Manager (ARM) template. The --template-file deployment/azuredepoy.json tells us the template is a file named azuredeploy.json located in the folder deployment. Notice that the application name is passed to a parameter myWebAppName, using the environment variable.
An ARM template is simply a flat file that a lot like a JSON document. Use can use any text editor, I like doing mine with Visual Studio Code and two extensions: Azure Resource Manager Snippets, and Azure Resource Manager (ARM) Tools With those tools I can build ARM template very efficiently. For this template, we need a service plane and a web App. Here what the template looks like.
This template is simple, it only contains the two required resources: a service plan, and a web app. To learn more about the ARM Template you can read my other post or check out this excellent introduction in the documentation.
Once the template is created and saved in its folder.
The deployment
There are only two last steps to the YAML file: the deployment and logout. Let's have a quick look at the deployment.
Now that we are sure the resources exist in Azure we can deploy the code. This will be done with azure/webapps-deploy@v1 that will take the package generated by dotnet into myapp. Since we are already authenticated there is no need to specify anything at this point.
Everything is ready for the deployment. You just need to commit and push (into master) and the GitHub Action will be triggered. You can follow the deployment by going into the Actions tab.
After a few minutes, the website should be available in Azure. This post only shows a very simple build and deployment, but you can do so many things with those GitHub Actions, like executing tasks or packaging a container... I would love to know how you use them. Leave a comment or reach out on social media.
Every week, I publish my reading notes. Those are the articles, blog posts, podcast episodes, and books that catch my interest and that I found interesting. It's a mix of the actuality and what I was looking for.
ASP.NET Core updates in .NET Core 3.1 (Sourabh Shirhatti) - I'm very excited about this 3.1 version.I'm not sure why maybe it's because it is the long-time support (LTS). Nevertheless, I will update all my projects.
Use Google Sheets to translate faster (Robin Kretzschmar) - Woo! That's pretty cool. Automatic translation is never the best but this is very convenient.
7 Dangers of Micromanagement ( Jack Wallen) - Nice post to help you give the best version of yourself. (Note it's now 6, but it was 7 when I read it)
It's coming! I'm not talking about winter here but I'm about Microsoft Ignite. One of the biggest Microsoft events for the DevOps and Dev amount us. This 4 days long event is a fantastic opportunity to get up to date with your favorite technology, learn the best practices, get certified and meet tons of experts to talk about your projects!
This year it's very special for me because I have the great pleasure to be part of the adventure, I will be presenting two sessions that are part of the Learning Paths.
A Learning Path is a series of connected learning modules that include sessions, hands-on experiences, technical workshops, certifications, and expert connections. Learning Path’s work together to build upon what you’ve learned to provide a comprehensive set of skills to help you reach your goals.
Figuring out Azure Functions (AFUN95)
Tailwind Traders is curious about the concept behind “serverless” computing – the idea that they can run small pieces of code in the cloud, without having to worry about the underlying infrastructure. In this session, we cover the world of Azure Functions, starting with an explanation of the servers behind serverless, exploring the languages and integrations available, and ending with a demo of when to use Logic Apps and Microsoft Flow.
Options for building and running your app in the cloud (APPS10)
See how Tailwind Traders avoided a single point of failure using cloud services to deploy their company website to multiple regions. We cover all the options they considered, explain how and why they made their decisions, then dive into the components of their implementation. In this session, see how they used Microsoft technologies like Visual Studio Code, Azure Portal, and Azure CLI to build a secure application that runs and scales on Linux and Windows VMs and Azure Web Apps with a companion phone app.
But wait, there is more...
For the second time, after the Microsoft Ignite "the event", will starts another event a tour! This year, it is thirty (30) cities that Microsoft Ignite The Tour will visits! All continents, except for Antarctica (why?! 😉), will be visited. Check the complete list of the cities on the website and mark the dates on your calendar!
I will also be presenting many different sessions during this tour. While I'm not doing all of them, I'll be present on many occasions.
Looking forward to meeting you
So if you are planning to go to one of those events, and would like to meet to talk about your project, show some bugs, ask questions, or just to chat! Reach-out, It's ALWAYS a pleasure, and I'll bring some stickers and some special swag1 with me...
How To Develop Apps Like PUBG (Apoorv Gehlot) - An interesting article that gives us an idea of how a game like pugs got that success, and who they manage that rapid growth.
It's so nice to be able to add some serverless components in our solution to make them better in a snap. But how do we manage them? In this post, I will explain how to create an Azure resource manager (ARM) template to deploy any Azure Function and show how I used this structure to deploy an open-source project I've been working on these days.
Part 1 - The ARM template
An ARM template is a JSON file that describes our architecture. To deploy an Azure Function we need at least three recourses: a functionApp, a service plan, and a storage account.
The FunctionApp is, of course, our function. The service plan could be set as dynamic or describe the type of resource that will be used by your function. The storage account is where is our code.
In the previous image, you can see how those components interact more with each other. Inside the Function, we will have a list of properties. One of those properties will be the Runtime, for example, in the AZUnzipEverything demo, it will be dotnet. Another property will be the connection string to our storage account that is also part of our ARM template. Since that resource doesn't exist yet, we will need to use the dynamic code.
The Function node will contain a sub-resource of type storageAccount. This is where we will specify where is our code, so it cant be clone to Azure.
Building ARM for a Simple Function
Let's see a template for a simple Azure Function that doesn't require any dependency, and we will examine it after.
The first resources listed in the template is the Account Storage. There nothing specific about it.
The Service Plan
The service plan is the second resource in the list. It's important to notice that to be able to use the SKU Dynamic you will need at least the API version of apiVersion to be "2018-02-01". Then you specify the SKU.
"sku": {
"name": "Y1",
"tier": "Dynamic"
}
Of course, you can use the other SKU if you prefer.
The Function App
Final resources added to the mixt, and this is where all the pieces are getting together. It's important to notice that the other in which the resources are listed are not considered by Azure while deploying (it's only for us ;) ). To let Azure knows you need to add dependencies.
This way the Azure Function will be created after the service plan and the storage account are available. Then in the properties we will be able to build the ConnectionString to the blob storage using a reference.
The last piece of the puzzle is the sub-resource sourcecontrol inside the FunctionApp. This will define where Azure should clone the code from and in which branch.
To be sure that everything is fully automatic the properties publishRunbook and IsManualIntegration must be set as true. Otherwise, you will need to do a synchronization between your Git (in this case on GitHub), and the Git in Azure.
Of course, all the source code of both the Azure Function and the ARM template are available on GitHub, but let me highlight how the containers are defined from an ARM template.
Just like with sourcecontrol, we will need to add a list of sub-resources to our storage account. The name MUST start by 'default/'.
Part 2 - Four Deployment Options
Now that we have a template that describes our needs we just need to deploy it. There are multiple ways it could be done, but let's see four of them.
Deploy from the Azure Portal
Navigate to the Azure Portal (https://azure.portal.com), from your favorite browser and search for "deploy a custom template" directly in the search bar located at the top of the screen (in the middle). Or go at https://portal.azure.com/#create/Microsoft.Template. One in the Custom deployment page, click on the link Build your own template in the editor. From there, you can copy-paste or upload your ARM template. You need to save it to see the real deployment form.
Deploy with a script
Would it be in PowerShell or in Azure CLI you can easily deploy your template with these two commands.
In Azure CLI
# create resource group
az group create -n AzUnzipEverything -l eastus
# deploy it
az group deployment create -n cloud5mins -g AzUnzipEverything --template-file "deployment\deployAzure.json" --parameters "deployment\deployAzure.parameters.json"
In PowerShell
# create resource group
New-AzResourceGroup -Name AzUnzipEverything -Location eastus
# deploy it
New-AzResourceGroupDeployment -ResourceGroupName AzUnzipEverything -TemplateFile deployment\deployAzure.json
Deploy to Azure Button
One of the best way to help people to deploy your solution in their Azure subscription is the Deploy to Azure Button.
You need to create an image link (in HTML or Markdown) to this to a special destination build in two-part.
However, this URL needs to be encoded. There is plenty of encoders online, but you can also do it from the terminal with the following command (A big thanks to @BrettMiller_IT who showed me this trick during one of my live streams).
Clicking the button will bring the user at the same page on the Azure Portal but in the user subscription.
Azure DevOps Pipeline
From the Azure DevOps portal (https://dev.azure.com), select your project and create a new Release Pipeline. Click on the + Add an artifact button to connect your Git repository.
Once it's added, you need to add a task the current job. Click on the link 1 job, 0 task (4). Now you just need to specify your Azure subscription, the name of the resource group and select the location of your ARM template inside your repository. To make the deployment automatic with each push in the repository, click that little lightning bolt and enable the Continuous deployment trigger.
Wrapping-up
Voila, you know have four different ways to deploy your Azure Function automatically. But don't take my word for it, try it yourself! If you need more details you can visit the project on GitHub or watch this video where I demo the content of this post.
