Category: Best Practices

Azure Best Practices

The following is a list of the best practices I have found in 18 months of learning and using Azure (not including the community blogs of course), I know best practice isn’t a great term but here are the links anyway, enjoy!

p.s. I’ll keep updating this so check back in a month or 2 🙂



Azure Devops – Add your build status badges to your Wiki

Its always a good idea on your project to keep your project documentation up to date, I personally like to make use of the Wiki inside Azure Devops, we use Azure Devops almost exclusively at work now.

On the wiki we have a page which documents the Azure Builds and Release pipelines, so that people can get an idea of what the individual builds are for and explain the steps within the Release pipelines, for the most part this is really straightforward, but for new people joining the team it just makes life easier to have this kind of thing written down and explained.

On that note I wanted to show you how to add the status badges for each build to your Wiki, it took me a wee while to find this so I thought I’d blog it because I’ll forget and so other people can see how to do it.

An example of the kind of thing I am talking about is below: –

So how do you find the Markdown for the badges so that you can add this to your wiki or elsewhere?

If you browse to your build(s) for your projects, click on the 3 ellipses on the right hand side, next to the Edit and Queue buttons and then choose Status Badge

Then you need to select the text next to Markdown, and then just paste this into your wiki page.

Hopefully someone finds this useful, bye for now.



Azure Devops – Release Gates

In this blog post I want to talk to you about release gates within Azure Devops, release gates can be useful if you want to add in some further pipeline checks to stop the release going ahead.

Nothing better than an example so here is how to set up gated releases using Azure Devops.


Example

This example shows how you can add in a release gate so that the release wont go ahead and deploy if say there are still open bug tasks within the Azure Board for the current sprint.

Once you have a release, first, click on the lightning bolt on the stage as seen below, and then enable the Gates are on the right hand side.

One this had been selected choose Add and then select Query Work Items, for this I have created a Shared Query where I created a shared query to show me if there are any bugs which are sitting as Approved (which I’m using as open but not started as yet), I don’t want the release to go ahead if there are any bugs in the Approved status.


Note:- In order to create a new query within Azure Devops on the left hand side select Boards, queries and then select new query.

An example query would look something like the following


Fill out the screen below like below and I set the upper threshold to 0.

To recap, I want my release to fail the gate so that the release wont go ahead because I have open bugs within my Azure Board for this particular project.

There are a number of different types of release gates you can use and here is a screen shot of the ones available to use at this time.

I hope you find this useful, if you have any questions please leave feedback.



Azure Policies

Unfamiliar with Azure Policies?

Azure Policies start off with you defining a policy within Azure which could be something as simple as implementing a naming convention for lets say a Virtual Machine.

The following policy definition states that when creating an Azure VM it must match the naming convention we specify


An example of how to do this would be as below (in JSON):-


So what we are saying here is that if any user tries to create a Virtual Machine within a Resource Group within Azure then it must be named something like VM-P-ABC-GS01.

To get started with trying this out within the Azure Portal search for Policy at the top of the Azure Portal and you’ll see a screen something like the below: –

Here I have loaded the Policy area of the portal for an existing project and you can see the level of detail and see that I have on overall compliance of 95% on my resources and listed are the Non-compliant state Resources (if I were to expand).

By clicking on any of the non-compliant areas I will be shown all of the non-conforming resources which is awesome.

With Azure policies in place we can enforce naming conventions for a Resource Group, if we want to go further we could use Azure Management Groups – which I will cover in a separate blog post.

But what if I already have resources in place and I want to start using naming conventions with Azure policies?

In that case we need to talk about the contents of a policy definition which you can read up on.

Lets review another Azure policy (in JSON)

In the screen shot above the import part here is the EFFECT part.

Effect

Policy supports the following types of effect:

  • Deny: generates an event in the activity log and fails the request
  • Audit: generates a warning event in activity log but doesn’t fail the request
  • Append: adds the defined set of fields to the request
  • AuditIfNotExists: enables auditing if a resource doesn’t exist
  • DeployIfNotExists: deploys a resource if it doesn’t already exist
  • Disabled: doesn’t evaluate resources for compliance to the policy rule

So if we have resource which we might want to change the name of going forward and we are able to then perhaps use Audit to start off with and then change them to Deny.

Note if you make use of Azure policies and use Azure Devops to create Infrastructure as Code (IaC) then the easiest place to find issues with failing releases is in the build summary log.

Summary

In summary, there is a lot more to Azure policies, here I just wanted to give you some idea of what you can use Azure policies for.


Tags:


Azure Governance and Security

Recently came across some very useful links for moving to Azure and thought they may be of some use to others as well, the content below covers things like best practice for subscriptions, resource group usage naming conventions, security and more…


 



How to Monitor changes in your Azure Resources

I was at a recent ThoughtWorks talk in Glasgow about Infrastructure as Code as it was something that was very relevant as to what I was looking into at the time

We wanted to take an Azure Resource Group (dev) and then deploy the entire thing to a new Resource Group (UAT) and use ARM templates and Azure Devops to accomplish this (I’ll cover this in another blog post soon).

But this made me think what happens if there is any drift, i.e. if someone manually changes a setting in the Azure portal then what? – I haven’t yet come to the point where I get alerts on drift but at least I found out where to monitor changes to resources you have within Azure.

So here you can see what was changed and by whom, so if someone was to say change an Azure Function AppSettings it would be shown here with a date and time as well, handy if you need to keep an eye on who changed what and when

 



Azure Devops: Test & Feedback Intro

Microsoft recently changed the name from Visual Studio Team Services (VSTS) and rename it Azure Devops.

They also added some new features one of which I will cover briefly to give you a flavour of what you do with it.

With Azure Devops Microsoft have a suite of tools which combined are very powerful and cover a number of topics which I will in turn cover over the next few weeks and months (there is a lot to cover).

This quick blog post will cover some of the functionality in the newly released Azure Test & Feedback.

So the clue is in the name,  and you can use this Chrome Browser extension tool to do the following and a lot more: –

  • Take Screenshots of bugs and have them added straight into your current sprint in your Azure Board (with browser details etc.)
  • Record videos of how you reproduce a bug and again have that added as a bug in the current sprint.
  • Create Test Cases (not looked into this enough yet), but looks very sweet indeed

The below is a screen shot of the extension and you can even watch the quick demo, you can get the Chrome extension here: –
https://marketplace.visualstudio.com/items?itemName=ms.vss-exploratorytesting-web

 

Download it take it for a test drive, you’ll be pleasantly surprised 🙂



VSTS and Git Integration for Deploying to Azure – Part 2

Ok so in this post (part 2) I promised to show you how to use Visual Studio Team Services (VSTS) to build, test and deploy your code to Azure.

Step 1 – Build your code using VSTS

Select Build and Release from inside VSTS like so

On the right hand side click where it says + New and you’ll see the next screen

I have rubbed out the names of the project I the above screen shot in case you’re wondering why it looks weird.

So here I’m saying that I want to use VSTS Git for where my source code belongs, I choose the Team Project, the Repository and which branch I am interested in building, then I select continue.

Now I need to select a template for the type of project I want to build like so.

I have chosen the Azure Web App for ASP.Net and then I click Apply.

On the next screen I need to choose

  • Name for the new Build
  • Which type of pool will I use to build the code
  • Locate the solution file for my project (from a selection)
  • I have chosen my Azure Subscription
  • And I have chosen the App service name from a drop down which comes from my Azure subscription.

 

Above you can see the list of steps which will be preformed

  1. Use Nuget
  2. Restore my Nuget Package(s)
  3. Build the solution
  4. Run any Tests within the solution
  5. Attempt to Deploy the App Service (this step I would normally always remove)
  6. Then VSTS publishes the artifacts to a Drop folder within VSTS which is later used in the Release part of VSTS to deploy the artifacts to Azure in tis case.

I will right click on step 5 and remove the App Service Deploy step as I just want to build my solution and create the deployment artifacts.

 

Ok so now you need to pay attention to this area of the build screen.

The red exclamation mark is showing us we need to fill out some further details before we can proceed, so lets fix this next.

So here we need to add a Branch Filter before it will allow us to Save the new Build.

And now we can either choose Save or Save and queue our new Build, I’ll select Save and queue.

 

And you’ll now see your Build queued.

 

One your build is there you more than likely want to setup continous integration, tick this checkbox inside Trigger.

 

 

 

In the screen above you click Enable Continous Integration and you can fill the screen below out

Join me in Part 3 – And I’ll walk-through deploying the code by creating a Release in VSTS for our new build artifacts.



VSTS and Git Integration for Deploying to Azure – Part 1

At work we use Visual Studio Team Services (VSTS) with git and in this post I’ll walk you through our development process for writing code and deploying it to a demo site on Azure.

I have become a big fan of VSTS, it has some cracking functionality built-in which saves you a lot of time and effort.

I will cover the following:-

Using Visual Studio 2017 with the git integration tools

So I open up Visual Studio 2017 and I first of all need to update my local copy of the master branch and pull down the latest version.

To do this I select Sync as shown above and then I choose fetch to fetch the latest commits and pull to pull them all down as below.


Ok, so now I have the latest code from the master branch as seen below.

Now I want to run the master branch and see if everything is good and check whats changed with the commits I pulled down but before I can do this I need to apply some local settings.

The reason for this is we have a number of Azure Services being used like event hubs etc and I have a local settings json file with my settings which I never check in. To apply these local settings I saved them into a stash and I will show you how I apply my stashes next.

So I click Stashes within Team Explorer and then I see the following.

 

And now I right-click on local settings and select apply stash, and this will apply my local settings to the project allowing me to run my own event hub instead of the one on our demo site as an example.

In order to get the Git Stash Extension you can download it from Extensions and Updates from the Tools menu within Visual Studio.

 

In Part 2 https://gregorsuttie.com/2018/08/24/vsts-and-git-integration-for-deploying-to-azure-part-2/ – I’ll show you how to use VSTS build pipelines to build and test your code and then deploy it to Azure.



Visual Studio Team Services – Gated Check-ins: How-To

So you using Visual Studio Team Services (VSTS) and you have some build definitions and your team are doing pull requests but you want their branch to run a build before the pull request is reviewed.

The steps to add gated check in are like so:-

  1. Log into VSTS
  2. Go to the Code Menu and then select Branches
  3. From the list of branches look to the right of master for 3 dots … (ellipses)
  4. Click the 3 dots and then select branch policies
  5. Look on the left under Branch policies
  6. Click on Add build Policy
  7. Choose your build pipeline
  8. Fill that out and then give it a name
  9. Make sure it’s enabled
  10. Now when a user goes to create a pull request and pushes they’re code
  11. The gated check-in will check that the users branch builds before anyone can review the pull request.

This add a quality gate to your check-ins using VSTS.

Hope that helps