Continuous Delivery with TFS: Creating an All-in-One TFS Server
In this third instalment of my series about creating a continuous delivery pipeline using TFS it's time to actually install TFS. In a production environment you will more than likely -- but not always -- split the installation of TFS across multiple machines, however for demo purposes it's perfectly possible and actually preferable from a management perspective to install everything on to one machine. Do bear in mind that by installing everything on one server you will likely encounter fewer issues (permissions come to mind) than if you are installing across multiple machines. The message here is that the speed of configuring a demo rig in Azure will bear little resemblance to the time it takes to install an on-premises production environment.
Ben Day maintains a great guide to installing TFS and you can find more details here. My recommendation is that you follow Ben's guide and as such I'm not planning to go through the whole process here. Rather , I will document any aspects that are different. As well as reading Ben's guide I also recommend reading the Microsoft documentation on installing TFS, particularly if you will ultimately perform an on-premises installation. See one of my previous posts for more information. One of the problems of writing installation instructions is that they date quite quickly. I've referred to the latest versions of products at the time of writing below but feel free to use whatever is the latest when you come to do it
- Start by downloading all the bits of software from MSDN or the free versions if you are going down that (untried by me) route. At this stage you will need TFS2013.4 and VS2013.4. I tend to store all the software I use in Azure on a share on my domain controller for ease of access across multiple machines.
- If you are following my recommendation and using a domain controller the first step is to create service accounts that you will use in the TFS installation. There is comprehensive guidance here but at a minimum you will need TFSREPORTS, TFSSERVICE and TFSBUILD. These are sample names and you can choose whatever you like of course.
- The second step is to create your VM with reference to my Azure foundations post. Mine is called ALMTFSADMIN. This is going to be an all-in-one installation if you are following my recommendation in order to keep things simple, so a basic A4 size is probably about right.
- Ben's guide refers to Windows Server 2012 because of SharePoint Foundation 2013's lack of support for Windows Server 12 R2. This was fixed with SharePoint 2013 SP1 so you can safely create your VM as Windows Server 2012 R2 Datacenter. Having said that, you don't actually need SharePoint for what we're doing here so feel free to leave it out. Probably makes sense as SharePoint is a beast and might slow your VM down. Ben's guide is for an on-premises rather than Azure installation of Windows so some parts are not relevant and can obviously be skipped.
- Early versions of TFS 2013 didn't support SQL Server 2014 and Ben's guide covers installing both SQL Server 2012 and 14. You might as well go for the 2014 version unless you have reason to stick with 2012.
- The TFS installation part of Ben's guide starts on page 99 and refers to TFS2013.2. The latest version as of this post is TFS2013.4 and you should go for that. As above my recommendation is to skip SharePoint.
- Go ahead and install the build service. On a production installation you would almost never install the build service on the TFS application tier but it's fine in this case.
- The build service (or more correctly the build agents) will need to build Visual Studio applications. The easiest way to enable this is to install Visual Studio itself -- VS2013.4 (whatever is the best SKU you are entitled to use) without the Windows 8 Phone components will do very nicely.
- You can leave the test controller installation for the time being -- we will look at that in detail in a future post.
When the installations are complete and the VM has been restarted you should be able to access the TFS Administration Console and check that all is in order. Congratulations -- your TFS admin box is up-and-running! Watch out for the next post where we create a Visual Studio development environment.
Cheers -- Graham
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:
Get-AzureVM -ServiceName AlmCloudService -Name ALMDC | Set-AzureStaticVNetIP -IPAddress 10.0.0.4 | Update-AzureVM
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
Creating a Continuous Delivery Pipeline from Scratch using the TFS Ecosystem
For anyone working with the Team Foundation Server ecosystem there are plenty of articles on how to get started with the individual components – TFS itself, Visual Studio, Release Management, Microsoft Test Manager and so on. Frustratingly though there is very little guidance on how to piece everything together to create continuous delivery pipelines that build code, automatically deploy it to an environment and then run automated acceptance tests.
Until now that is, because over the next few months I’m going to document my experience of building a continuous delivery pipeline – in my case using IaaS in Microsoft Azure. As each post is written I’ll update my Continuous Delivery with TFS page which will serve as a handy reference for anyone wanting to work through the process. If you are interested in knowing more about the philosophy about continuous delivery then have a look at this article and also this one. Both of these refer to the Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation book which is the current authoritative text on this subject and which I definitely recommend anyone working in this area should read.
Cheers – Graham