Now I’m ready to put it all to the test!
I know there’s been a lot of build-up, and the previous two articles really just explored the setup experience. This article explains the scope of my professional development journey, so we won’t get into the meat of things until the next article.
As I found out.. there’s more to the configuration than I’d previously realised. Read on to see how I’ve configured my test VM environment (and refer to the above two articles if you’re new to configuring Visual Studio or Team Foundation Server – although a local TFS instance is optional if you are following along).
The Product Suite
Here’s the specification of my test VM environment:
|Host||Microsoft Windows Server 2012 Standard|
|Memory||4 GB (Dedicated)|
|HDD (System Drive)||60 GB (Fixed Size), recommend 80 GB as installs and OS take up 49 GB|
|Secondary HDD||60 GB (SCSI)|
|Development IDE||Visual Studio 2013 Preview (see configuration, below)|
|Database||SQL Server 2014 Enterprise Edition Evaluation CTP 1|
|Source Control||Team Foundation Server 2013 Preview (Single Server)|
|Web Browsers||Internet Explorer 10, Firefox 23, Chrome 29|
A note about Team Foundation Server 2013 installation
At the end of the installation process, the installer dumps out some interesting info. These changes are made to the local system
The most notable changes are the setting of IIS’s dynamic compression, as it affects any website hosted on the IIS service, and the increase in Windows service start timeout from 30 seconds to 600 seconds – how long do they anticipate it might take TFS services to start? Why on Earth don’t they offload (parallelise) some of that workload?
Visual Studio 2013 Installation Options
That done, I’m ready to fire up Visual Studio 2013. Here’s a look at the installation options I chose when I initially configured Visual Studio. Note that I’m not anticipating using LightSwitch/Silverlight, design tools (like Blend) or Office/SharePoint/Windows Phone developer tools.
The first thing you’ll probably want to do is install the NuGet Package Manager for Visual Studio 2013. There are plenty of other add-ins available from the Visual Studio Gallery, the fastest way to narrow down the selection of available options, is to filter by version, scroll down and check out the left hand side navigation:
Most of the time I automatically a set of standard tools onto each development environment, I’ll discuss what’s included there in a later post.
Sign in with a Microsoft Account?
Last time, I mentioned that Visual Studio prompts you to sign in with a Microsoft Account. At the time, I didn’t go down that avenue, but this time curiosity bit me, so I used some credentials.
Viewing your profile (via the supplied link) takes you to a fairly generic looking account page. Despite the Spartan appearance, there’s value to be had here. If you look to the right hand side, under the “Accounts/Owner” heading, you have an opportunity to create a VisualStudio.com TFS workspace.
Clicking on the link takes you to a new page where you can choose a workspace name. All you have to do now is open Visual Studio and click on Team –> Connect to Team Foundation Server. Click on “Select Team Projects…” in the Team Explorer window, and go from there.
So besides carrying your Visual Studio preferences around, there is some added value in using a Microsoft Account.
Scope of the Exercise
I’m going to be doing a couple of things with this pre-release software. I’m going to build up a website using Visual Studio 2013, adding an Entity Framework layer and finally using SQL Server 2014.
My source dataset for this exercise will be my Twitter archive; I’ll be importing it into SQL Server and then creating a meaningful schema. This schema will be exposed as an EF data model and ultimately consumed by a bootstrap-enabled website.
Will be exploring SQL Server 2014 CTP 1 and importing my Twitter archive into a new database, creating a new schema.
Recently, Microsoft released a preview version of their next version of their team development suite, known as Team Foundation Server (TFS).
Long time readers of Sanders Technology will know that I’ve a long history with TFS, and I’m genuinely a fan of the platform.
Team Foundation Server 2013 breaks from the naming convention used in some of the more immediate releases – 2008, 2010 and 2012 all being two years apart – the only exception being the first release, 2005.
So What’s New in 2013?
The big ticket items are certainly around source and build control.
The 2013 edition continues to build upon the support for another source repository system which will be known to many developers – Git. Initial integration featured in TFS 2012, and continues to be even stronger in TFS 2013.
Here’s a quick summary of some changes in Team Foundation Server 2013 Preview:
- Git built in to Visual Studio and TFS
- Use branches to switch contexts and isolate risk
- Resolve conflicts
- Work around a few known issues
- Build Windows 8.1 Preview Store apps
- Build more simply. Build in Git!
To learn more about what’s new in Team Foundation Server 2013 Preview, I’d encourage you to read the Visual Studio ALM Team Blog here. To see how it dovetails with new features coming in Visual Studio 2013, check out Brian Harry’s excellent blog here.
We’re going to take a look at this – and probably more – but first we have to install it!
Given this is a preview edition, I’m going to assume that most folks aren’t going to jump on this release and put it into production, but if you are so inclined (as a fresh install or as an upgrade), you can do so – particularly as upgrading is supported – but as per normal, caution is advised.
The first – absolute first – thing you should do is go and download the installation and administration guides.
The install media (.iso) contains a link to this location on Microsoft.com where you can obtain the latest installation guides. I strongly recommend doing this, even if you’ve installed and configured TFS as many times as I have (or more).
For review purposes, I’m installing TFS 2013 Preview on a clean Windows Server 2012 VM, and I’ll be installing just a ‘Standard Single Server’.
Beginning the Install
Before getting underway, I strongly urge a review of the installation pre-requisites to ensure that you have met the requirements for the type of installation you prefer. In this release, the installation supports – ‘Basic’, ‘Standard Single Server’, ‘Advanced’ and ‘Upgrade’ of the Team Foundation Application Server. Note that there is also the option to install the Application Tier and Data Tiers separately.
There is also support for installing the usual suspects – TFS Server Proxy, TFS Build Service and Extensions for SharePoint Products (you’ll recall that with TFS 2012, SharePoint became an optional dependency).
Standard Single Server
The diagram to the left comes from the Installation Guide and illustrates what we’ll be introducing with our TFS 2013 configuration.
Notice that the standard installation uses both a local SQL Server instance (configured for Reporting Services and Analysis Services) as well as a local SharePoint Web Application.
This significantly decreases the number of inbound/outbound ports which are required as the TFS Application and Data tiers are self-contained within the same host.
Upgrade is supported from TFS 2010 (with or without SP1) and any Go-Live version of TFS 2012 to the TFS 2013 Preview. Upgrading from TFS 2008 is no longer supported, you would have to upgrade from TFS 2008 to an earlier version first. For more on upgrade scenarios and considerations, check out the MSDN Blog for more details.
As stated above, I’m going to be going with the ‘Standard Single Server’ configuration. A quick scan of the Installation guide reveals the steps I need to undertake:
To install a single server configuration you need to install SQL Server before proceeding to install Team Foundation Server 2013. Supported versions of SQL Server are:
- The next version of SQL Server (Express,¹ Standard,¹ and Enterprise editions)
- SQL Server 2012 with SP1² (Express,¹ Standard,¹ or Enterprise Editions)
Note that this would appear to exclude previous versions of SQL Server, particularly 2008 R2. I’ve chosen to install SQL Server 2012 Standard Edition for this review.
Kicking off the Installation Media
Once you’ve dealt with the prerequisites, you can begin installing TFS 2013.
We’re greeted with the now, familiar cut down installer. It’s essentially a tick of a box and the clicking of an oversized button, and we’re off.
Once the initial components are in place (mine required a system reboot), we are met with the familiar Configuration Center. I select ‘Standard Single Server’ and click the “Start Wizard” button.
For the Standard configuration, you just need to provide a local user account which TFS will use as the service account for SharePoint and SSRS (read only, for accessing TFS reports). For everything else, TFS will use the standard Network Service account.
Installing Optional Pre-requisites: SharePoint Foundation 2013
Now, the installer does some interesting checks. In this particular case, the VM I’m running only has 2GB of RAM (scalable to 4GB).
The installer detects the server as not having enough minimum memory, and therefore gives me an opportunity to skip the SharePoint installation and configuration.
I’m actually wanting to have a look at the SharePoint integration, so I restart and shift the RAM up to the minimum (4 GB). Problem solved.
This time around, I have the option to install SharePoint Foundation 2013, but I’m warned that it will suffer from performance degradation as I’m running at less than the recommended RAM – 10 GB (memory hog!).
This pops up a couple of other installation dialogs as we progress. A couple of system restarts are required,
Eventually, we get towards the finish of the SharePoint component. Depending on your system’s performance, this could take a little while.
The Main Event
Once the readiness checks have finished (I was tripped up by Reporting Services not having been properly configured), you can click on “Configure” to start the final work.
The final configuration is error-free, and on the final page we’re given a link to click on so we can access our newly minted TFS 2013 (Preview) instance:
Coming Up Next…
Now that we have a fully functioning TFS 2013 build, it’ll be time to dig into it some more. Stay tuned for the next article where we will explore Team Foundation Server 2013 (Preview) using Visual Studio 2013 (Preview) and Team Explorer!
Recently, I had to authenticate to Team Foundation Server using an account with greater permissions to perform some administrative tasks. As you may know, this requires entering alternate credentials when you add the server to the list of TFS servers, or when you need to connect to the server. Once you’ve connected once, you aren’t prompted again as the credentials are cached locally.
In the past, to remedy this, you could simply delete the local TFS cache, which is located in the following directory (Windows Vista and onwards):
<system drive>\Users\<your profile>\AppData\Microsoft\Team Foundation
However, in more recent versions this has changed somewhat, and the user’s credentials are no longer linked to the local TFS cache or configuration.
Where are the Credentials?
Good question. After some digging about, it seems that the credentials are now stored in the user’s Credential Manager store within Windows. If you aren’t familiar with this, it was introduced on the more recent versions of Windows, and it lives via the Control Panel, under the following path: Control Panel->User Accounts
Inside this location, you can view all the locally cached credentials, including Windows Credentials:
Note: that it appears that for TFS credentials used by Team Explorer and other applications, the credentials are the ones under “Generic Credentials” not under “Windows Credentials” (in case you have TFS entries in both).
To modify or remove the credentials you use to connect to TFS, simply expand the appropriate entry and click on “Edit”, or to delete the local credentials, click on “Remove”. If you opt to remove the credentials, you’ll be prompted to enter new credentials next time you connect to the specified TFS server.
So that was a little out of the way. When I tested this, I made sure that I’d disconnected from TFS before changing/removing the credential configuration.
It would be nice if Team Explorer linked to the Credentials Manager so we didn’t have to go digging to work this out, wouldn’t it?
The series so far:
Following on from an earlier series of articles on TFS Azure comes this update. Recently, Microsoft integrated cloud-based build controllers to streamline the process of getting your automated builds online.
This is an excellent alternative to having to procure and configure your own on-premise build machine, and means that you can create basic build definitions with little overhead.
Where we left off..
In the previous article, we had configured an on-premise build server which hosted and performed local build services for our TFSPreview TFS instance. This was the only option in the initial release of TFS Azure as there were no cloud based build services available.
I recently created a new TFS Team Project to allow some collaboration. I’d been in discussions last month with local Microsoft TFS expert Grant Halliday, he’d mentioned that there was now a cloud-based build controller option available.
Today I uploaded a very basic solution comprising of a console application and a Unit Test project. Adding the cloud-based CI capability was easy as pie.
Configuring Your Cloud Build Controller
1. Once you have a valid solution in source control, simply right click on the Builds item in your Team Explorer and select “New Build Definition”:
2. Give your new build a name:
3. Configure the build trigger (notice all the regular options exist):
4. Next, set the build workspace(s) as per normal:
5. This is where it gets interesting. You configure the build defaults, but there are some interesting options when using the cloud-hosted build controller:
Note that “Hosted Build Controller” is in the list of controllers available. There is also an option which checks build output into source control (no need for a build share!)
6. There are also much the same options for the build process as you’d expect with an on-premise controller – and you can add your own build definitions as per normal. Note that there is a new definition here also – “AzureContinuousDeployment” which we might touch on in another article.
7. Once you’ve set your retention policy, you are good to go.
Executing a build
Treat it like any other build controller/build host! You can manually execute or (if you’ve configured gated check-ins or CI build definitions) just make some changes and commit.
You can even watch the building process in real-time, just like a non-Cloud-hosted build controller:
Couldn’t be easier! Obviously, if your build process or solution require any special steps you may hit a wall with the hosted build controller. This capability though, might be useful for selected branches of a large solution in which you wished to place gated check-ins/continuous integration, where the output is unit testing + classes.
All I can say is – this is a step in the right direction.