Maintaining and operating (server) applications in an IT infrastructure is costly. You need staff for installation, configuration of the applications, and monitoring. TFS is no exception. As the use of TFS increases in a company, there is usually a need for scaling up and out the server platform to handle the load. The more important TFS becomes in an organization, the greater the need for maintenance and good backup/restore solutions.
Companies increasingly have started to use cloud-based solutions for much of their infrastructure functions. Vendors such as Google, Microsoft, and others offer cloud services for other companies and organizations. Microsoft, for instance, offers the Office365 concept including email, shared calendars, IM, video conferencing and document collaboration.Moving part or all of an organization’s IT services to a cloud vendor makes it possible to reduce the number of functions in the internal IT infrastructure. Hence, the cost associated with maintaining and operating these services will be reduced.
To address these issues, Microsoft has made Visual Studio Team Foundation Server 2012 available in the cloud, running under Windows Azure. This chapter will cover TFS in the cloud and the pros and cons associated with this. Let’s start by looking at the Windows Azure platform.
Windows Azure Overview
The Windows Azure Platform is a cloud application platform that allows Microsoft datacenters to host and run applications. It provides a cloud operating system called Windows Azure that serves as a runtime for the applications and provides a set of services that allows development, management, and hosting of applications outside of the organization. All Azure Services and applications built using them run on top of Windows Azure.
Windows Azure has three core components:
Let us take a look at these.
Compute
Compute provides a computation environment with
- A web role customized for web-application programming, as supported by Internet Information Services (IIS) 7 and ASP.NET. Web roles run in full IIS 7.0.
- A worker role that is useful for generalized development and that may perform background processing for a web role.
- A virtual machine (VM) role thatprovides a user-customized image to make it easier to move existing Windows Server applications to the Windows Azure hosting environment.
Storage
Storage focuses on providing scalable storage:
- Blob service, for storing text or binary data
- Queue service, for reliable, persistent messaging between services
- Table service, for structured storage that can be queried
Relational Database functionality is offered through SQL Azure, a version of SQL Server that runs on the Azure platform.
Fabric
Fabric is the networking underpinnings of the Windows Azure platform and uses high-speed connections, and switches to connect nodes consisting of several servers together.
Fabric resources, applications, and services running are managed by the Windows Azure Fabric Controller service. It acts as the kernel of the Windows Azure distributed-cloud operating system, providing scheduling, resource allocation, device management, and fault tolerance for the nodes in the fabric. It also provides high-level application models for intelligently managing the complete application lifecycle, including deployment, health monitoring, upgrades, and de-activation (http://en.wikipedia.org/wiki/Azure_Services_Platform).
The Azure Platform
The Windows Azure platform uses a specialized operating system, called Windows Azure, to run its fabric layer. This is a cluster hosted at Microsoft’s datacenters and it manages the computing and storage resources of the computers. It also provisions the resources (or a subset of them) to applications running on top of Windows Azure. Basically, Windows Azure can be described as a cloud layer sitting on top of a number of Windows Server systems. These use Windows Server 2008 and a customized version of Hyper-V, Windows Azure Hypervisor, to provide virtualization of services.
The platform includes five services:
- Live Services for communication and collaboration services
- SQL Azure (formerly SQL Services) for data-storage services
- AppFabric (formerly .NET Services) for cloud-computing services
- SharePoint Services for web-content-management and document-management services
- Dynamics CRM Services for customer-relationship-management services
As developers, we can use these to build the applications that will run in the cloud. A client library, in managed code, and associated tools are also provided for developing cloud applications in Visual Studio. Scaling and reliability are controlled by the Windows Azure Fabric Controller, which prevents the services and environment from crashing if one of the servers crashes within the Microsoft datacenter, and provides the management of the user’s web application, such as memory resources and load balancing.
TFS on Azure
Note Keep in mind as you read this chapter that as of this writing, TFS on Windows Azure is still in preview. This means that much might change before the first version is released. The URL http://tfspreview.com will change, and many features might be different. The good news is that the version available at the time of writing is very stable, and open for everybody.
As mentioned, Microsoft now offers TFS as a cloud service. Instead of connecting to a local server, we connect to a cloud version of TFS. One difference though is that TFS in this case stands for Team Foundation Service, not server. This is to show that it is a service that Microsoft provides, not an application. Figure 34-1 shows our Eclipse development environment in Mac OSX connecting to a cloud-based TFS instance.
Figure 34-1. Connecting to a web URL instead of an on-premises TFS server using Eclipse in Mac OSX
Getting Started
Getting started with Visual Studio Team Foundation Service in the cloud is easy. Microsoft provides a web-based signup procedure that enables teams to quickly get started with the service.
This is how you get started. Browse to http://tfspreview.com and see the screen in Figure 34-2. A video will tell you more about the cloud version of TFS.
Figure 34-2. The Team Foundation Service logon page (at the time of writing)
Proceed by clicking Create Account. Fill in all details of the Account Signup screen and click Sign Up (see Figure 34-3). TFS will ask for a Windows Live ID. If you don’t have one you can create one from the web page directly. You also need to fill out the Server URL that all TFS users need to use when they connect to your instance of TFS. Once you have signed, in you are ready to get started (Figure 34-5). From the screen in Figure 34-4, you can start creating your TFS projects, add team members, watch tutorials, download necessary software, and more.
Figure 34-3. Signup screen (at the time of writing)
Figure 34-4. You can manage your TFS instance From this management screen
Figure 34-5. Creating your first project
The first thing you need to do is to create a team project. Do this by clicking on Create Team Project. This will start the Create Team Project wizard (Figure 34-5). Choose the name of the project and which process template you want to use. You are presented with three options for the process template:
- Microsoft Solutions Framework for Agile
- Microsoft Solutions Framework for CMMI
- Microsoft Visual Studio Scrum
Once you are done, click Create Project and wait for the wizard to finish. This will take a few minutes, and then you are presented with a completion screen.
Once the project is created, you can go to the team project home page (Figure 34-6), where you are presented with a web page that looks exactly like the web-access page in a Team Foundation Server. This makes the experience really seamless if you are used to a local TFS.
Figure 34-6. The team project home page
To access the new project from your Visual Studio development environment, enter the URL to the cloud TFS in the connect server properties (Figure 34-7). Now you are ready to develop using a cloud service.
Figure 34-7. Connecting to the Team Foundation Service URL in Visual Studio 2012
You can now add your team members to the service. As TFS is hosted in the cloud, Visual Studio Team Foundation Server 2012 is available to all your team members regardless of location. They just need to sign in and provide their credentials.
This solution is ideal for geographically dispersed teams or for collaboration with stakeholders on remote locations. If you have a network connection, you can access Visual Studio Team Foundation Server 2012 from anywhere.
The tfspreview site offers extensive documentation (Figure 34-8). The documentation will take you through every step from creating your first TFS project to connecting Visual Studio to checking in code to creating work items to setting up agile project management, and so on.
Figure 34-8. The documentation will help even an inexperienced user set up a hosted TFS instance
Services Offered With TFS in the Cloud
Using TFS in the cloud is very much like having a local TFS server on our site. We can do pretty much everything that we can do with a local install, including:
Let’s look at some of these to see what does and does not differ from a local TFS server.
Source Control
Source control works just as it does in a local TFS installation, which is good. We can access the source-control system from Visual Studio as we would in an on-premises scenario and from the web-management page.
Work-item tracking is available just as on a local TFS server. There are no real disadvantages to using the work-item system in TFS in the cloud. You can achieve the same traceability in the same way as you can on a local install.
The biggest drawback here is that we currently cannot change the work items provided in the service. This means we are limited to the work items Microsoft has selected for us and the information available in them.
This service differs a bit from the local TFS installation. For automation of high-level processes, which is one of the important ALM pillars (see Chapter 2), it is essential to be able to create new templates, adjust templates, or maybe delete templates. Being able to adjust TFS to support our process of choice is a great benefit of TFS. In the cloud version (as of this writing), however, we do not have the option to tailor TFS to accommodate our needs. We are stuck with the process templates that Microsoft offers and cannot add any of our own. Neither can we adjust the templates to add more information in, for example, the work items, or change workflows and so on.
Microsoft, we hope, will change this in the final or future versions. There is nothing wrong with the templates that Microsoft offers (MSF for Agile, MSF for CMMI and Microsoft Scrum), but it is a pity that we cannot change anything of this ourselves for now.
Testing
At this point, there is no special hosted TFS services for testing. We can, however, connect Microsoft Test manager to a cloud-based TFS and store our test cases and test results there, which is great. On the other hand, what would we be looking for as cloud-based testing services? Several interesting areas to consider include:
- Using the cloud to host a test environment
- Automatic deployment to Azure
- Load testing on a cloud-based test rig
For more details on testing in the cloud, switch back to Chapter 23, which has a section about lab management using Azure VMs. Chapter 22 talks about load testing on Azure VMs, and Chapter 27 discusses deployment to Azure as well as how to implement a build-deploy-test workflow on an Azure VM.
With the Hosted Build service, Microsoft has made it possible to use a shared pool of hosted build machines (though we can still install and manage build machines on-premises with hosted TFS). We can do more than just build—as with on-premises TFS, we can run a default workflow that include compilation, testing, and more. We can also create a custom workflow that does whatever we like.
The build service works by maintaining a pool of machines that can expand and shrink as needed. When we start a build, a VM is allocated from the pool to run our build. The build is run, the build output is copied off the build machine, and then the VM is restored and it is returned back to the pool for someone else to use. Yes, the machine is wiped clean after every build, so we need not worry about someone accidentally getting our code from a previous build.
This means that we can avoid having to setup a local build environment if we don’t want to. For some (perhaps smaller) organizations, this can be very useful as they don’t have to invest in hardware and maintenance of the build environment, but instead can use the cloud version and still get the benefits of the build features.
Chapter 26, on build automation, shows how to work with the hosted build service, and Chapter 27, on deployment, explains how to implement a complete build-test-deploy workflow using cloud services.
Getting good reports from your ALM tools is essential to get visibility into the project and its status. In Team Foundation Server, there are lots of reports out of the box, and also ways we can create our own reports. The same reports are available when we use Team Foundation Service, however. We get the burndown chart and the velocity chart, as shown in Figure 34-6, but not much else.
Another drawback is that we cannot create our own reports, so we need to be happy with the ones Microsoft provides. This is a weak point for TFS in the cloud so far, at least from an ALM perspective. It would be better if Microsoft could extend the reporting functionality in Team Foundation Service.
Let us take a look at some of the benefits of using TFS in the cloud. From the ALM overview in Chapter 2, we remember that collaboration is a key concept. Using TFS in the cloud can help us enhance collaboration, especially with external contributors and developers who travel frequently. It can also enhance collaboration in an organization with geographically spread locations.
Using TFS in the cloud, we do not have to set these users up in our local network. Neither do we need to provide VPN access and other security solutions for remote users ourselves, or to perform operating-system or software upgrades, make backups, patch the server, or respond in the middle of the night to hardware or power failures. This reduces the cost of maintaining such infrastructure, regarding network and hardware costs and also regarding staff costs, since Microsoft (or your selected vendor) takes on the burden of infrastructure security and monitoring.
By using TFS in the cloud, we can quickly and easily add new users to our TFS environment. We can also provide access to TFS wherever our users are located. All they need is an Internet connection and the correct rights in the TFS environment. In the end, this simplifies collaboration in our projects, since we do not have many barriers to get us started.
Since we have access to work-item tracking, build services, test tools, and almost everything available in a local TFS server, we can also get traceability and visibility in the same way as with a local TFS installation.
Another benefit is that the cloud based TFS version will be updated frequently, even more often than the updates will be offered to a boxed TFS version. Microsoft will push out updates as they create them on the cloud service.
Concerns with TFS in the Cloud
One disadvantage with TFS in the cloud is that we can neither add our own process template nor make adjustments to the existing templates. This means that we cannot adjust TFS to all our needs in the company. If we need more information in a work item, we cannot add fields or change work flows to suit our needs. Instead, we are stuck with the structure that Microsoft offers.
Another concern is the weak support for reports, which makes visibility suffer from an ALM perspective.
Summary
All in all, Team Foundation Service is a great addition to any development organization that does not want to maintain and support a Team Foundation Server installation on its own premises.
Team Foundation Services provides most of the ALM features we should strive for—with one big exception. We do get traceability, visibility, collaboration, and so on, but also we get (so far) limited control over the automated process, since we cannot change the process templates that are available to our teams. Or change these templates ourselves. One huge benefit of the hosted service is that it can evolve much faster than what we are used to, so expect the gaps we see today between the hosted service and TFS on-premises to close quickly. And then we will see the latest innovations appearing on the service first.