Click here to Skip to main content
15,881,803 members
Articles / All Topics
Technical Blog

Continuous Delivery with TFS: Laying the Azure Foundations

Rate me:
Please Sign up or sign in to vote.
4.00/5 (1 vote)
7 Mar 2015CPOL4 min read 5.4K   2  
Continuous Delivery with TFS: Laying the Azure Foundations

This article is an entry in our Microsoft Azure IoT Contest. Articles in this section are not required to be full articles so care should be taken when voting.

For anyone interested in creating a continuous delivery pipeline with TFS, this is the first article in a series of posts that will explain how I created my demo pipeline. I’ve used Azure IaaS (i.e., virtual machines configured with specific roles such as IIS), however if that’s not an option for you, then it should be easy to translate everything to your way of working – virtualisation, actual physical servers, etc. I won’t be going in to very much detail about using Azure so if you are new to Azure, see one of my previous posts here for details of how to get started, and make sure you are familiar with its IaaS capabilities, i.e., how to create and remote desktop to VMs.

Many technologies have both a quick-and-dirty way of doing things and also a more considered way. Azure is no exception and if you don’t make any alternative arrangements creating a new virtual machine in Azure will create a new storage account and a new cloud service. Things can quickly get out of hand and you end up with stuff all over the place and the possibility of using credits faster than you intended. To keep things tidy, it’s best to create some foundations upon which you can create your VMs. Buck Woody has a great post here which explains the steps and is mostly still relevant even though the post dates back to April 2013. I’m not going to repeat the detail of the post here, but this is a summary of what you need to set up:

  • Affinity Group – Keeps a set of resources together which can help to minimise costs. Choose a region that makes sense for all of the VMs you will create.
  • Virtual Network – Allows all of the VMs to talk to each other. At the time of Buck Woody’s post, it was possible to specify an Affinity Group for a Virtual Network but this has now changed and you can only specify a region. You can read more about this here, but when you create your network, choose the same region as the Affinity Group.
  • Storage Account and Container – This is where the VHDs of your VMs are stored. Choose the Affinity Group you created previously. When your Storage Account is running, create a Container called vhds.
  • Cloud Service – This is the container in which all of your VMs will live. You can create a new Cloud Service at the same time as creating a new VM but I prefer to create one up front, specifying the previously created Affinity Group.

In the spirit of keeping things neat and tidy when I create a new set of the above resources, I like to use a naming convention which consists of a short prefix plus the name of the resource I’m creating, e.g., AlmAffinityGroup, AlmVirtualNetwork and so on. Bear in mind that some of the names – in particular the Cloud Service – need to be globally unique so it’s worth navigating to the first page of the Cloud Service wizard (which will validate names you put in) to find something that is likely to work before you start in earnest.

Once all the above are in place, it’s worth creating a test VM – it’s simple to delete it once you have finished testing. I tend to create my VMs with PowerShell and will post about this in the future, but for the meantime in the Portal, you can choose New > Compute > Virtual Machine > From Gallery. Choose Windows Server 2012 R2 Datacenter (or whatever might have superseded this) and move on to the next step of the wizard. I always use the latest version, and choose the basic tier as it’s cheaper, and for a test VM choose an A0 size, again to keep costs down. Supply a name for the VM and a username and strong password and then at the next step in the wizard you can supply all the resources you created above.

On the subject of keeping costs down, it’s worth noting that to ensure you don’t get charged when you are not using your VMs, you have to actually shut them down from the portal or use the Stop-AzureVM PowerShell cmdlet so that their status is Stopped (Deallocated). Simply powering off from within the VM isn’t enough. Automating this is the way forward – another future post!

Cheers – Graham

The post Continuous Delivery with TFS: Laying the Azure Foundations appeared first on Please Release Me.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


Written By
United Kingdom United Kingdom
Dr Graham Smith is a former research scientist who got bitten by the programming and database bug so badly that in 2000 he changed careers to become a full-time software developer. Life moves on and Graham currently manages a team of software engineers and specialises in continuous delivery and application lifecycle management with the Team Foundation Server ecosystem.

Comments and Discussions

 
-- There are no messages in this forum --