How to Use Github Professionally (Aaron Stannard) - This post is great! Tons of information and best practices (with an explanation of why its a best practice).
I really enjoyed this book. Yes it's light and funny, but don't get fool, there is a deeper message here. I think Jessy wins his challenge by going into a monastery so we don't have to. We all have what it takes to live a more purposeful life, we just need to pause. Showdown, to go faster, do less to do more... Embrace the silence.
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.
How to Use External Storage in Docker (Brett Fisher) - Nice short episode that explains how to think (or when to think) about storage while working with containers.
#313: 3 Steps to Finding Freedom to Focus (Ken Coleman and Michael Hyatt) - The work-life balance... not an easy thing to answer... I enjoyed this episode exploring, suggesting a way to improve (get closer) to a balance.
Ubuntu, with Mark Shuttleworth (Craig and Adam) - It was so nice to learn more about Mark Shuttleworth and his projects. Like always... an awesome episode.
418: The Way to Nurture New Ideas, with Safi Bahcall (Dave Stachowiak) - Very interesting episode where we learn that there are always multiple sides to a story... And knowing them will change our perception.
403: Transition Well Through Your Day, with Gretchen Rubin (Dave Stachowiak) - Doing a little bit of catching up with this podcast, but I'm glad I did! Not only the episode was good but now I have to books that I'm really looking forward to read!
Install WSL 2 on Windows 10 (Thomas Maurer) - Awesome tutorial. If like me you didn't want to wait until the next Windows release or take the time to compile and debug a deployment....this tutorial is for us!
Atomic Habits: An Easy & Proven Way to Build Good Habits & Break Bad Ones (James Clear) - An excellent book that is very pleasant to read. I really appreciated the way things are broken in tiny pieces. I don't think this book re-invented the molecular physic, but by cutting, dissecting our habits that way it's hard to think that you can fail. It's easier to get started right now; even starting new habits before finishing the book!
Top 15 Visual Studio Code Extensions in 2019 (Gift Egwuenu) - Nice list of extension that targets primarily JavaScript developers but there's definitely a few gems for all of us.
Podcast
Anthos Migrate, with Issy Ben-Shaul (Kubernetes Podcast from Google) - Nice update. I like the talk about Anthos it look like a great migration tool. I need to find that GitHub repo...
First steps with Docker and Kubernetes - Introduction (Matteo Pagani) - Wow, fantastic post to get started with Kubernetes the author mention that after reading this you won't be an expert... However, you will definitely know enough to be dangerous.
How to become a Git expert (Aditya Sridhar) - A very nice post that explains how to fix common mistake users does and also explains how to keep our history clean.
Web Architecture 101 (Jonathan Fulton) - This is a very complete article that does a tour of every piece of a web solution.
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.
Most of the time when we use an Azure Devtest Lab it to Test our own application. This means that will need to install them on the virtual machines, every time. To do that, we need to create a custom artifact and add it to our formulas or to our claimable VMs. Lucky for us, creating a custom artifact is much easier than you may think. In fact, this post I will show you how easy it can be.
Goal
I want to create an artifact available from a private repository (Git from dev.azure.com in this case) that will set the timezone inside the VM.
Getting started
First, let's use a section in the Azure portal that is very useful; the Get Started section. In the portal navigate to your DevTest Lab (1), and select the Getting Started option from the left menu bar (2). In this new bar scroll down to the Lear more area and select Sample artifacts and scripts (3).
That will open the DevTestLab artifacts, scripts and samples project from Azure on Github. Open the folder Artifact, to see the list of all the usual artifacts you find in the public repo that is available by default in the portal.
Notice how all artifacts are in their own folder. When you create a new artifact, you can always come here and pick something similar to what you are trying to do. This way, you won't start from scratch. Let's open windows-vsts-download-and-run-script. An artifact is defined in the file Artifactfile.json. This file is mandatory and cannot be renamed. You can put scripts, images, or anything else you need inside this folder.
Open the Artifactfile.json file and have a look.
As you can see it's a simple JSON file. In the section (A) you will define the title, description, publisher, OS and the Icon. Note that the Icon must be accessible publicly, it could be on github, a blob storage or on a website. Section (B) is to define all the parameters you may need to install your artifact on the VM. Finally In (C) it's the command to execute.
Create the Artifact
Here is the JSON for our windows-Set-TimeZone artifact. A made it very static by not passing any parameter, but in a reel situation, a timezone parameter would be better.
Artifactfile.json
{
"$schema": "https://raw.githubusercontent.com/Azure/azure-devtestlab/master/schemas/2016-11-28/dtlArtifacts.json",
"title": "Set TimeZone to Eastern Standard Time",
"description": "Execute tzutil command on the VM set set the Time Zone",
"publisher": "FBoucher",
"tags": [
"PowerShell"
],
"iconUri": "https://raw.githubusercontent.com/Azure/azure-devtestlab/master/Artifacts/windows-run-powershell/powershell.png",
"targetOsType": "Windows",
"parameters": { },
"runCommand": {
"commandToExecute": "tzutil.exe /s \"Eastern Standard Time\""
}
}
Create an artifact repository
For this post, I'm using Git from Azure Devops (dev.azure.com) previously named VSTS, but any private repository should works. If it's not already done create a project and go to the Repos section. Create a root folder named Artifacts or something else if you prefer. Then add a new folder for your artifact. To follow the best practices you should start with the name of your artifact by the name of the targeted OS; in my case windows-Set-TimeZone. Now add the file Artifactfile.json defined previously.
Note the url of the repository, it should be easy to get it by click on the Clone button that is on the top right of the screen.
Add repository to DevTest Lab
Now we need to add this repository to our Devtest Labs. From the portal.azure.com, open the blade of your lab. From the left panel, click on Repository, then click the Add button.
It's time to use the information noted previously. This is about the Repository, not the artifact.
Use the Artifact
The only thing left is to use our artifact. You can find it while creating a VM or a formula. When you have parameters define in your Artifactfile.json, the parameters will be listed in a form completly a the left.
And if you try it, you will see that the time match the desired timezone. Here my PC is set to display with a format of 24H put it's the same... yep I'm in Eastern Standard Time.
Add it to an ARM template
Doing it with the nice interface is good when you are learning. However, we all know that no DevOps will do that manually every time. So let's add our Repository to our ARM template. If you need more detail on the deployment method, I explain it in a previous post How to be efficient with our Azure Devtest Lab deployments.
When you don't know the type or the structure of a resource, you can always go in the Resource Explorer (resources.azure.com) there will be able to find your resource and see how it's defined.
So for this post our artifactsources will look like this:
An artifactsources goes in the Resources list inside the Devtest Labs.
In an ARM template you have the main node Resources (A), then you will have the Lab node (B). Inside this node, you should see second resources list (C), where the Virtual Network is defined. The artifactsources should go there.
Then when you declare your formula, you just need to reference this repository, exactly like the public one.
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.
Git Commands to Keep a Fork Up to Date (Phil Nash) - Git can be overwhelming at the beginning, this is why this post is a great one to confirm what you may already know and learn a bit more.
LINQ Challenge #3 (Mark Heath) - Okay, I know I'm not a LINQ expert but ... I'm curious to see the answers and will definitely give it a try.
Unit Testing in ASP.NET Core Web API (Milos Davidovic) - Great tutorial that explains every bit of the inversion of control and how to create your unit tests.
Imagine you just arrived at the office. You only took a sip or two of your coffee or tea. You look at the tasks that need to be done today (well yesterday based on the request): a new project is starting, and you need to configure everything the team needs to start building that web application. The need a repository, a continuous integration and continuous delivery (CI/CD) pipeline, a place to deploy, monitoring tools, and of course you need to create an environment where they will be able to track their work. Should you panic? No, because you will use the new Azure DevOps Project available in Azure.
Let's Create the project
From the Azure portal (portal.azure.com) click on the plus button and search for "devops". Select DevOps Project, then click on the Create button. Then follow the five steps and Azure will create everything for you.
What is deployed
Your application from many popular frameworks
Automatic full CI/CD pipeline integration
Monitoring with Application Insights
Git Repository
Tasks/ Bugs tracking board
Deployment to the platform of your choice
In Video please!
Conclusion
The DevOps projects are really fantastic and are very useful. The fact that everything is all packaged together and automatically deployed is a considerable time saver. In short, are the Azure DevOps projects worth it? Oh yeah!
Do you have to know English to be a Programmer? (Scott Hanselman) - Interesting post... At the end, English may not be a blocker...but you need some base. Otherwise, how could you even read this post!