Archives for Continuous Delivery with TFS

Continuous Delivery with TFS: Creating a Domain Controller

In this second post in my series about creating a continuous delivery pipeline using TFS I describe how to create a domain controller in Azure. It's not mandatory -- it's perfectly possible to use shadow accounts and that's how I started -- however the ability to use domain accounts makes configuring all of the moving parts much simpler. It also turns out that creating a domain controller isn't that much of a chore.

Create the VM

The first step is to create a Windows Server VM using the foundations configured in the first post in the series. I use a naming convention for groups of VMs so my domain controller is ALMDC, and since this VM won't be doing a lot of work size A0 is fine. If you have other VMs already created they should be deallocated so you can specify the first none-reserved IP address in the allocated range as static. For my Virtual Network in the 10.0.0.0/25 address space this will be 10.0.0.4 -- previous slots are reserved. If you create the VM using PowerShell you can specify which IP should be static when the VM is created. If you use the Portal you can do that later which is the technique I'll describe here. See this article for more details.

Configure the VM for DNS

Whilst the VM is being provisioned head over to your virtual network and select the Configure panel and add your new server and its IP address as a DNS server, as it will be also performing this role. You should end up with something like this:

Once the DC has been provisioned you use your version of the following PowerShell command to specify a static internal IP for a previously created VM:

This command needs to be run from an admin workstation that has been configured to work with Azure PowerShell and your Azure subscription. You need to install Azure PowerShell (easiest way is via the Microsoft Web Platform Installer) and then work through configuring it to work with your Azure subscription, details here. If all that's too much right now you can just make sure that your DC is the first VM in the cloud service to start so it uses the IP specified as DNS.

Install and Configure Active Directory

One you are logged in to the domain controller install the Active Directory Domain Services role via Server Manager > Add roles and features. After rebooting you will be prompted to install Active Directory and to specify a Fully Qualified Domain Name -- I chose ALM.local. Defaults can be chosen for other options. Next, install  the DNS Server role. I deleted the Forwarder entries (Server Manager > DNS Manager > Tools and choose Properties from the shortcut menu of the  DNS node and select the Forwarders tab) but I'm not sure now if that was absolutely necessary. You can check if everything is working by accessing a well-known website in IE. One point to note is that you shouldn't manually change the NIC settings of an Azure VM as that can lead to all sorts of trouble.

Although I've mentioned previously that you need to shut down your VMs so they show their status as Stopped (Deallocated) in the portal to avoid being charged I actually leave my DC running all the time as it only costs about £4 per month and I like to know that when I start my other VMs I have a fully functioning DC for them to connect to.

Cheers -- Graham

Continuous Delivery with TFS: Laying the Azure Foundations

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 (ie 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, ie 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, eg 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