Category: Best Practices

Jan27201927 January 201927 January 20198Commentsby Gregor Suttie

Azure Policies

Posted in Azure, Best Practices

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:

Nov11201811 November 201811 November 20180Commentby Gregor Suttie

Azure Governance and Security

Posted in Azure, AzureDevOps, Best Practices

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…

 


Sep20201820 September 201820 September 20181Commentby Gregor Suttie

How to Monitor changes in your Azure Resources

Posted in Azure, Best Practices

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

 


Sep20201820 September 201820 September 20181Commentby Gregor Suttie

Azure Devops: Test & Feedback Intro

Posted in Azure, Best Practices

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 🙂


Aug24201824 August 201826 August 20183Commentsby Gregor Suttie

VSTS and Git Integration for Deploying to Azure – Part 2

Posted in Azure, Best Practices, Continuous Deployment, VSTS

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.


Aug24201824 August 201826 August 20182Commentsby Gregor Suttie

VSTS and Git Integration for Deploying to Azure – Part 1

Posted in Azure, Best Practices, Git, VSTS

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.


Aug0220182 August 20184 August 20181Commentby Gregor Suttie

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

Posted in Best Practices, VSTS

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


Jul18201818 July 201818 July 20187Commentsby Gregor Suttie

Microsoft Azure Infrastructure and Deployment (beta) AZ-100

Posted in Azure, Best Practices

The following is a study guide for the AZ-100 Azure exam

Manage Azure subscriptions and resources (15-20%)
Manage Azure subscriptions

Analyze resource utilization and consumption

Manage resource groups

Implement and manage storage (20-25%)
Create and configure storage accounts

Import and export data to Azure

Configure Azure files

Implement Azure backup

  • May include but not limited to: Configure and review backup reports; perform backup operation; create Recovery Services Vault; create and configure backup policy; perform a restore operation

Deploy and manage virtual machines (VMs) (20-25%)
Create and configure a VM for Windows and Linux

  • May include but not limited to: Configure high availability; configure monitoring, networking, storage, and virtual machine size; deploy and configure scale sets

Automate deployment of VMs

  • May include but not limited to: Modify Azure Resource Manager (ARM) template; configure location of new VMs; configure VHD template; deploy from template; save a deployment as an ARM template; deploy Windows and Linux VMs

Manage Azure VM

  • May include but not limited to: Add data discs; add network interfaces; automate configuration management by using PowerShell Desired State Configuration (DSC) and VM Agent by using custom script extensions; manage VM sizes; move VMs from one resource group to another; redeploy VMs

Manage VM backups

  • May include but not limited to: Configure VM backup; define backup policies; implement backup policies; perform VM restore

Configure and manage virtual networks (20-25%)
Create connectivity between virtual networks

Implement and manage virtual networking

Configure name resolution

Create and configure a Network Security Group (NSG)

Manage identities (15-20%)
Manage Azure Active Directory (AD)

Manage Azure AD objects (users, groups, and devices)

Implement and manage hybrid identities


Feb18201618 February 201619 February 20162Commentsby Gregor Suttie

MSWebDay – What I took away from it

Posted in Best Practices, Events, JavaScript, KnockoutJS, MVC, NuGet, Training

Today, Feb 16th, I attended MSWebdevday ran by Microsoft in Glasgow which was an event covering all things web related from Microsoft, the speakers were @christosmatskas, @thebeebs and @martinkearn and was an all day event.

The Schedule for the day covered various topics and it was great to learn so many new things and get my first glimpse at some new technologies, I always love learning something new, and I even sat next to the illustrious Gary Ewan Park, someone who I have chatted to a few times on twitter but not every managed to meet.

Ok so lets cover the actual event:-

The first talk was by on What’s New in ASP.Net Core 1.0 and was a tour of the new features, how to get it, how to use it, whats new, whats no longer there and he also talked about how you can just take the files and drop them into a folder when deploying, there’s no gac, you can just deploy the Core files in a folder alongside your code, this is very neat, its cross-platform, and it means you could have the same site running under different version of Core going forward should you choose to or need to have this.

The second Talk was Building with JavaScript Task Runners, this was mainly about how to get gulp, how to set it up and how to run some tasks to minify your css, javascript files and all that good stuff, how to add it into Visual Studio as a build step after you compile your code, showed an example gulp file and lots more.

The third talk was Entity Framework Core 1.0, and covered EF and how to use it, how to use code first and also mentioned EF6 how its improved greatly from previous versions and why you should choose this version at the moment whilst EF Core 1.0 is still being worked on and has the tooling added to it for the Core 1.0 release.

The fourth talk was APIs: the cogs behind the machine and this talk was about api’s and mainly web api and how in Core 1.0 there is no MVC and WebAPI its just one thing now and your controller is an API controller, so no need for MVC and WebAPI there is just the controllers now which kind of merge both together.

The fifth talk was Dev Ops in Azure and this covered deploying your website to Azure, making changes, showing the changes, getting the publisher file for using in side Visual Studio and publishing your changes from Visual Studio using Git int his example to deploy your changes from within VS up to the new Azure portal.

The sixth talk was Hitchhikers Guide to JavaScript, this talk focused on ECMAScript and the future of JavaScript and basically how a lot more code that we write will be JavaScript and we saw examples of the features coming in the next few years etc.

The seventh talk was Web Performance and how to check your websites performance using tools like YSlow and Google Page Speed etc and then how to go about making it make far less requests, cache JavaScript, enable IIS features and how to optimise images etc to make your website perform much faster that it currently does.

The eight talk was Single Page Applications and was about KnockoutJS and Angular, talking about Angular 2 and how it makes use of TypeScript and showed code covering KnockoutJS and AngularJS.

The ninth talk was about Hybrid Web Apps and how you can create application that can appear as Windows 8/10 tiles, make use of Microsoft Office and showed some very neat stuff using ManifoldJS which is itself very cool stuff.

Other stuff mentioned
I wrote some notes during the talks (should have taken a lot more) but a couple of things I need to look at are listed below:-

Summary
The event was great, full days learning, a lot of content covered, great speakers and good turn out. Spoke to some guys I chat to on twitter and all in all an awesome day spent learning some new stuff. There was a lot of content, I’ve missed half of it I’m sure so take a look at the slides on the site at MSWebdevday.

Dear Microsoft can we have some more of these days please? – especially Azure and Core related content.


Jan25201625 January 201625 January 20160Commentby Gregor Suttie

Technical Debt in your team

Posted in Best Practices

technicaldebtOn twitter recently I read a few people talking about technical debt and how it occurs and how to best tackle it, so here is my view on said subject.

Technical Debt

Technical debt comes in many forms, shapes and sizes and almost every team/developer is aware of technical debt within your company.

Over the years I’ve worked in several companies most of which knew they had a fair bit of technical debt and did very little about it, sometimes nothing, so here are a few examples and how to go about fixing your technical debt:-

We didn’t write it
So the developers who wrote the code have all left, ok then task a couple of current developer to report on this project and ask them to give your team a heads up on the state of the code base and there suggestions for removing this as technical debt, either get people up to speed with the code base, document the current state of the code base and perhaps even find out if its worth re-writing but by all means do something with this technical debt.

Don’t let it mount up over time, It’ll be like the cupboard or the attic in the house where you put all the stuff you don’t want look at and that is not where you want to get to.

If the code is apart of your projects then your team owns that code, no one else does, it’s not an excuse.

The code is written using old technology
Same as above, then document it, offer suggestions to get it up to newer technologies and task people with doing something about it, don’t let it remain in the state it currently is.

The code has no tests
Same as before, get a developer up to speed with it and write unit tests, refactor the code and document they’re findings, it won remain technical debt for very long

Summary
I realise that some technical debt there is just nothing you can do, maybe you don’t have the source code for it or you don’t have any developers who know the language well enough to update the application, perhaps no one in your team knows how it’s supposed to work. The thing here is to try your very best to do something with your technical debt and as a team talk about it, work at decreasing the amount of technical debt your team owns, take actions to fix, document, rewrite or whatever but do something about it now, don’t let time drag on and just let it grow.

Don’t start on new features unless they are critical and fix your technical debt, it could make the next persons job a lot easier and that can only be a good thing.

Document your solutions, the number of times I have started looking at code and asked what does this do and no one in the team can answer the question is quite scary, that should never be the case in my opinion.