Monday! It is time to share my reading notes. It is a habit I started a long time ago where I share a list of all blog posts that catch my interest during the week.
If you think you may have interesting content, share it!
Debugging distributed systems is hard! (Dennis Frühauff) - This is a very nice post that explains clearly a situation. How many of us have been in this situation before where you try to debug a system and it's just so hard?
Healthcare and Life Sciences Blog (Kyle Raymond) - This is a cool tutorial/ example that explains what is and how to use semantic Kernel.
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.
Moving your ASP.NET applications to the Microsoft Cloud (Premier Developer) - If you are thinking to migrate to the cloud, it's important to plan your migration. This post is the perfect point to get started, it contains references to deeper books and documents.
The Rise of Microsoft Visual Studio Code (Lyn Levenick) - Cool statistics about editor usage. Not sure of the real correlation with the editor used and the skill level, but it's still an interesting coincidence.
Stream Deck Tricks for Streamers… and Muggles too! (Jeff) - Fantastic post that explains so much why that little thing can save you so much pain. As THE day when I'm starting to stream get closer and closer... This is gold.
I'm about to start a new project and want to have it with a continuous integration (CI) and continuous deployment (CD). I've been using VSTS for a while now but didn't have the chance to try the new pipelines. If you didn't know VSTS as been rebranded/ redefined as Azure Devops. Before going in with the real thing I decided to give it a try with a simple project. This post is to relay those first steps.
Get Started
Let's start by creating our Azure Devops project. Navigate to Dev.Azure.com and if you don't already have an account create one it's free! Once you are logged-in, create a new project by clicking the New project blue button in the top right corner.
You will need to provide a unique name and a few simple information.
The Application
First thing first, we need an application. For this post, I will be using a simple Asp.Net Core site. For the repository, we have options. AzureDevOps (ADOps) support many repository: GitHub, Bitbucket, private Git and its own. Because the project I've created is public I decided to keep the code at the same place as everything else.
From the left menu, select Repos. From here if the code already exist just add a remote repository, or clone the empty one on your local machine, the usual. Create and add your code to that repository.
The Azure WebApp
The next step is to create a placeholder for our CD pipeline. We will create an empty shell of a web application in Azure with these three Azure CLI commands. You can execute them locally or from the Cloud Shell. (Don't forget to validate that you are in the good subscription)
az group create --name simplegroup --location eastus
az appservice plan create --name simpleplan --resource-group simplegroup --sku FREE
az webapp create --name simplefrankweb --resource-group simplegroup --plan simpleplan
The first command will create a Resource group. Then inside of this group we create a service plan, and finally we create a webapp to the mix.
Continuous Integration
The goal is to have the code to get to compile at every commit. From the left menubar, select Pipelines, and click the create new button. The first step is to identify where our code is, as you can see Azure DevOps is flexible and accept code from outside.
Select the exact repository.
This third step displays the YAML code that defines your pipeline. At this point, the file is not complete, but it's enough to build, we will come back to it later. Click the Add button to add the azure-pipelines.yml file at the root level of your repository.
The build pipeline is ready click the Run button to execute it for the first time. Now at every commit, the build will be triggered. To see the status of your build just on to into the build section from the left menubar.
Continuous Deployment
Great, our code gets to compile at every commit. It would be nice if the code could also be automatically deployed into our dev environment. To achieve that we need to create a Release Pipeline. And our pipeline will need artifacts. We will edit the azure-pipelines.yml to add two new tasks. You can do this directly in the online repository or just from your local machine; remember the file is at the root. Add these commands:
Those two tasks are to publish our application (package it), and make it available in our Artifact folder. To learn more about the type of command available and see example have a look the excellent documentation at: https://docs.microsoft.com/azure/devops/pipelines/languages/dotnet-core. Once you are done, save and commit (and push if it was local).
From the left menubar, click on e the Pipeles, select Release, and clienk the New Release blue button. Select the template that matches your application. For this post Azure App Service deployment is the one we need.
The next thing to will be to rename the environment for something else than Stage 1, I named mine "to Azure" but it could be dev, prod or anything that make sense for you. Click on the Add an Artifact button.
You will now specify to the pipeline were to pick the artifacts it will deploy. In this case, we want the "output" of our latest build. And I renamed the Source alias as Drop.
To get our continuous deployment (CD) we need to enable that trigger by clicking on the little lightning bolt and enabled it.
The last step to configure the Release pipeline is to specify a destination. By clicking on the "1 job, 1 task" in the middle of the screen (with the little red exclamation point in a circle), that will open the window where we will do that.
Select the subscription you would like to use, and then click on the Authaurize button on the right. Once it's done go change the App Service Name. Click on it and wait 2-3 seconds you should see the app we created with our Azure CLI display. Select it, and voila!
Now add a ReadMe.md file by checking out the code on your local machine or directly in Azure DevOps. Grab a badge from the build and/or release and copy paste it in the ReadMe. To get the code snippet of your badge, go to your build/ release definition, and click the ellipse button. Select Status badge and copy the snippet that matches your destination file (in our case the Markdown).
Now when you go to the Overview page, you will have a nice badge that informed you. It also works on any web page just use the HTML snippet instead.
Introduction to Azure Durable Functions (Maxime Rouiller) - This is a great post that explains what are durable functions and shows a simple case to gives context.
The Five Dysfunctions of a Team: A Leadership Fable (Patrick Lencioni) - I really enjoyed this book. The fact the first the material was passed as a story adds a lot of perspective and to our comprehension. In the last chapter the author return to the theories and gives more details. I completely devour that book; I'm looking forward to reading more.
Miscellaneous
paddling.com (Wayne Horodowich) - I could not agree more.
1575 Coding on Twitch with Jeff Fritz (Carl Franklin, Richard Campbell, Jeff Fritz) - Yep developers are also on twitch and they rock. We learn how it all started in this episode.
Azure functions are great. I used to do a lot of "csx" version (C# scripted version) but more recently I switched to the compile version, and I definitely loved it! However, I was looking for a way to keep my deployment short and sweet, because sometimes I don't have time to setup a "big" CI/CD or simply because sometimes I'm not the one doing the deployment... In those cases, I need a simple script that will deploy everything! In this post, I will share with you how you can deploy everything with one easy script.
The Context
In this demo, I will deploy a simple C# (full .Net framework) Azure functions. I will create the Azure Function App and storage using an Azure Resource Manager (ARM template) and deploy with a method named Zip push or ZipDeploy. All the code, script, a template is available on my Github.
The Azure Functions Code
The Azure Function doesn't have to be special, and it can be any language supported by Azure Functions. Simply to show you everything, here the code of my function.
namespace AzFunctionZipDeploy
{
public static class Function1
{
[FunctionName("GetTopRunner")]
public static async Task Run([HttpTrigger(AuthorizationLevel.Function, "get", "post", Route = null)]HttpRequestMessage req, TraceWriter log)
{
log.Info("C# HTTP trigger function processed a request.");
string top = req.GetQueryNameValuePairs()
.FirstOrDefault(q => string.Compare(q.Key, "top", true) == 0)
.Value;
if (top == null)
{
dynamic data = await req.Content.ReadAsAsync< object>();
top = data?.top;
}
return top == null
? req.CreateResponse(HttpStatusCode.BadRequest, "Please pass a number to get your top x runner on the query string or in the request body")
: req.CreateResponse(HttpStatusCode.OK, new { message = $"Hello, here is your Top {top} runners", runners = A.ListOf(int.Parse(top)) });
}
}
class Person
{
public string FirstName { get; set; }
public string LastName { get; set; }
public int Age { get; set; }
}
}
It's a really simple function that will return a list of Person generated on the fly. The list will contain as many person as the number passed in parameter. I'm using the very useful GenFu library, from my buddies: ASP.NET Monsters.
The only thing we need to do is to create our compress file (Zip or Rar) that contains everything our project required.
In this case, it's the project file (AzFunction-ZipDeploy.csproj), the function's code (Function1.cs) the host (host.json) and local settings of our function (local.settings.json).
The ARM template
For this demo, we need one Azure Function App. I will use a template that is part of the Azure Quickstart Templates. A quick look to the azuredeploy.parameters.json file and we see that the only parameter we really need to set is the name of our application.
To be able to ZipDeploy, we need to add one Application Setting to let the Kudu interface we need its help to compile our code. To do that let's open the azuredeploy.json and go to the appSettings section. We need to add a new variable named: SCM_DO_BUILD_DURING_DEPLOYMENT and set it to true. After adding the setting it should look like this (see the last one... that's our new one):
Now that all the pieces are ready it's time to put it together one script. In fact, only the two last commands are required; everything else is just stuff to make it easier to re-use it. Check out my previous post 5 Simple Steps to Get a Clean ARM Template, to learn more about the best practices related to ARM template. So let's see that script, it's pretty simple.
# script to Create an Azure Gramophone-PoC Solution
resourceGroupName=$1
resourceGroupLocation=$2
templateFilePath="./arm/azuredeploy.json"
parameterFilePath="./arm/azuredeploy.parameters.json"
dateToken=`date '+%Y%m%d%H%M'`
deploymentName="FrankDemo"$dateToken
# az login
# You can select a specific subscription if you do not want to use the default
# az account set -s SUBSCRIPTION_ID
if !( $(az group exists -g $resourceGroupName) ) then
echo "---> Creating the Resourcegroup: " $resourceGroupName
az group create -g $resourceGroupName -l $resourceGroupLocation
else
echo "---> Resourcegroup:" $resourceGroupName "already exists."
fi
az group deployment create --name $deploymentName --resource-group $resourceGroupName --template-file $templateFilePath --parameters $parameterFilePath --verbose
echo "---> Deploying Function Code"
az functionapp deployment source config-zip -g $resourceGroupName -n zipdeploydemo --src "./zip/AzFunction-ZipDeploy.zip"
echo "---> done <--- code="">
The only "new" thing is the last command functionapp deployment source config-zip. That where we specify to the Azure Function App to look to --src to get our source. Because I'm running it locally, the path is pointing to a local folder. However, you could execute this command also in the CloudShell, and that would become a URI... to an Azure Blob Storage by example.
Deploy and Test
If you didn't notice yet, I did my script in bash and Azure CLI. That because I want my script to be compatible with all platforms. Of course, you could have done it in PowerShell or anything else that would call the REST API.
To deploy, just execute the script passing the ResourceGroup name, and its location.
./Deploy-AZ-Gramophone.sh cloud5mins eastus
To get to Function URL, go to the Azure portal (portal.azure.com) and click on the Function App that we just deploy. Click on the function GetTopRunner in this case, and click on the </> Getfunction URL button.
Use that URL in postman and pass another parameter top to see we the deployment ws successful.
In Video Please
If you prefer, I also have a video version of this post.
Azure Application Architecture Guide (Mike Wasson) - A free book (pdf only) with all the best of the AzureCAT team? You really don't want to miss that opportunity.
Understanding Azure Event Grid ( Jason Roberts) - Nice little post that introduces event grid, differentiate it from the service bus, and quickly go over the pricing.
It's had been a while since I worked into Visual Studio Team Services (VSTS), and it was a real pleasure to get back in that area. For the solution I was working on, we need to keep the current database up and running while deploying a new version. For this purpose, we decided to append the release number to database name (ex: MyDatabase363). In our Build and Release processes, we needed to identify which databases are from the last release. In this post, I will show what I did using an inline PowerShell script to get that number and set it as an environment variable so it can be accessible by other tasks.
To get started let's add a Azure PowerShell task to our build definition. In this post, I use a build process but of course this is also valid for release process. To find the task quickly, use the search text box. I will add two of those, one to get the number, the second to validate that this value is now set as an environment variable and readable from other tasks.
Now it's time to set the first task. Fill-out all the properties and select Inline Script as the Script Type. It should look like this.
Let's examine the code.
Get last Release Number
$matchingResources = Find-AzureRmResource -ResourceNameContains "mydatabase" -ResourceType "Microsoft.Sql/servers/databases"
$lastRelease = 0
ForEach($resource in $matchingResources)
{
if ($resource.ResourceName -match '(\d)+$') {
if($lastRelease -lt $matches[0]){
$lastRelease = $matches[0]
}
}
}
Write-Output "The last release number is: $lastRelease"
Write-Output ("##vso[task.setvariable variable=lastReleaseNumber;]$lastRelease")
On the first line, I use the Azure PowerShell commandlet Find-AzureRmResource1 to get an array of all the databases currently online in my resource group that contains a specific string. In this case, it's the name of the database without the release number. Then I will loop through all returned resources and using a very simple Regex to extract the release number and keep the biggest one (the last release).
To close that script we have two outputs. The first one is to give feedback in the logs, because it's always good to have some information there. The second one look more complicated, but if you split it, it's easier to see what's happening. In fact, we are producing a VSTS (previously called Visual Studio Online this is why it's VSO) command to initialize a variable ##vso[task.setvariable variable=lastReleaseNumber;] And of course, assign to it our last release number $lastRelease
To validate that we really successfully found our last release number and assigned it to a variable, let's try to read it back but from another step. That will be easily done this code in the other step created:
Validate the last Release Number
$number = $env:lastReleaseNumber
Write-Output "Confirmation, the last Release Number is: $number "
The only thing missing before we can run our test is to create that environment variable. To to it simply go in the Variables tab and add it there.
It's all set, run the build and you should see something similar in your logs.
Announcing the Coco Framework for enterprise blockchain networks (Mark Russinovich) - You probably eared the buzz word blockchain before, but still not sure what it is exactly… Here is a good post to get started and in the meantime, you will know also an open-source framework to work with.
Managing your resources with Azure Cloud Shell (Corey Sanders) - My first thought about Cloud Shell was: cute. And then I was in a situation where … well, it really helped me. So yeah, definitely something to look at, and this post is the perfect starting point.
5 Common Myths Around Moving to Docker (Megan Rees Ahigian ) - Nice post that answers some very frequent assumptions related to container and more particularly, Docker containers.
Web Scraping In Power BI And Excel Power Query (Gil Raviv) - Just recently I've learned about Power BI web scrapping capability, then this! I didn't think it could be that great! Great post.
What’s New in Visual Basic 2017 (The Visual Basic Team) - It's been a while since I coded in VB but reading this post brought back all those souvenirs... Great work.
Securing Web Applications - Simple Talk (Vishwas Parameshwarappa) - Security should be in our priority in this time of APIs and IoT.... Excellent post to get started with multiple security breaches and how to fix them.
Tuples In C# (Mahesh Chand) - Tuples are one feature introduced in .Net 4.0 that can simplify our life a lot. Learn how in this post.
Getting to Know #Azure Mobile App - Nice tutorial that leverage the recently GA Azure Mobile App to build AskAlex: an universal application that looks promising...;)
Exception Handling with Logic Apps (Jeff Hollan) - Great tutorial that shows how to solve a extremely frequent problem... the exception handling.
Using Logic Apps Webhook Triggers (Jeff Hollan) - Fantastic tutorial that shows how to create an HTTP trigger in today's interface/ designer.
First look at Application Insights (Andrei Dzimchuk) - Excellent post. Perfect to make your idea about why and how we should use Application Insights. Nice touch to the config.
Cloud
Integration with Azure Service Bus (Vincent-Philippe Lauzon) - Great post that summarizes best practices and important tips related to Azure service Bus.
Get the DocumentDB SQL query cheat sheet (Aravind Ramachandran) - Confuse sometime with the syntax of noSql, this post shared a cheatsheet that should be saved (or printed).
Recently, with my team, we needed to upgrade a web solution to Azure SDK from 2.4 to 2.5.1. The upgrade was much longer and complex then expected, so I decide to share what we learn so maybe other could benefit from our experience.
The problem
The upgrade of the code and library was not really a problem. The documentation is available on MSDN and it's easy to follow. Few breaking changes were part of the version 2.5. One is the reason of this post: Diagnostics configuration must be applied separately after deployment[...]
(this post is also available in French)
This post is about creating an automatic deployment that could be used by everyone. I picked Dropbox as source control because today mostly everyone got is account. If you need one, feel free to use this invite it will gives you 500 MB of bonus space for free!
Step 1: Configure the automatic deployment
To configure the deployment, connect to the Azure management portal. Although the new portal is my favourite to manage and visualize information on websites, as I write this post the features needed for the Dropbox deployment were not yet available. We must connect to "old" portal and select the Web site. You a website is not already created you can add one using the quick create.
After selecting the site, you need to click on the option: Set the deployment from source control, which is located at the bottom right of the dashboard code.
From the dropdown list, choose Dropbox and click the arrow. Microsoft Azure deployment will now aks you to have to access on a directory in your Dropbox account.
Step 2: Publish Web Site
From your computer, access Dropbox. If you left the default settings, the directory should be under Apps / Azure / [dirname]. You can now copy the code, images and all other files that you need. After synchronization with DroxBox completed (the small green checks everywhere) you can return to Azure portal.
It is now time to deploy. To do this you need to click Sync.
Once completed you'll get a message informing you that the deployment is done. You can now check the log to see the deployment steps in detail if you wish.
The new version of your website is now available!
Conclusion
Deploy a blog, a static business site, a family owned site with Dropbox is so simple! It`s even better than the good old FTP, if something goes wrong, you can redeploy by one click.
Microsoft Azure Media Services - This article explains how works Azure Media Services by following a real case step by step.
Programming
Getting Started with Git and GitHub (Dhananjay Kumar) - Very clear and simple tutorial that explains the basic command of Git Prompt and Git in VisualStudio.
Suggestion of the week
![IMG_20150425_120539[1]](http://lh3.googleusercontent.com/-2Q54J7ToRU0/VT2UBvGqIQI/AAAAAAAAU7k/S0mUuk0Xh_E/s1600-h/IMG_20150425_120539%25255B1%25255D%25255B8%25255D.jpg "IMG_20150425_120539[1]")
