Entries tagged 'tfs' ↓

It’s been a while since I blogged anything complimentary about TFS / Team System, so I thought I’d mention that I appreciate the improvements to the build details screens in VS2010.

Here’s how a particular completed build appeared in VS2008:

 

And here’s how the exact same build appears in VS2010:

 

A little effort on the UI has really improved the user experience here.

I particularly like the cute graph of recent build durations and outcomes. This is useful for builds that are currently taking place, as you get an idea of how long the build is likely to take to complete:

There are many things I love about Team Foundation Server, but the supplied diff/merge tool is not one of them. It is - how can I put this? – somewhat basic. Indeed, I’ve heard tell of people going out of their way to avoid merges purely because they find the process so clunky.

Here’s the good news – you can easily configure TFS to use a different, third-party, diff/merge tool, perhaps the one you’ve grown to know and love over many years of happy software development using other SCM products. Maybe you like WinMerge, or love TortoiseMerge. Perhaps you’re like my friend John and swear by SourceGear DiffMerge. Or maybe, like me, you’re a Beyond Compare fanboy. No problem, they can all be used by TFS. Here’s how:

• Open up the Visual Studio options (Tools –> Options).
• Expand the Source Control –> Visual Studio Team Foundation Server section.
• Click the Configure User Tools… button:

• Click the Add… button to set up a new file extension operation:

• Set up a Compare operation to run against all files (extension of *):

• Repeat the process to add a Merge operation to run against all file extensions.

At this point, you’re probably thinking “wooah, what do those argument parameters mean? How do I know what to enter?”. MSDN won’t help you out (“type any arguments that your tool requires” – thanks for that!).

Fortunately James Manning has posted a blog article which not only explains what the argument parameters mean, but also suggests recommended parameters for various popular tools, including those mentioned at the beginning of this post. Thanks, James! 

Voila! OK your way back out of the dialog boxes, and your Compares and Merges will now be displayed using your favourite Diff/Merge tool. Feel your productivity and confidence soar!

Earlier this week I picked up a hire car and headed over to deepest Cheshire to install an instance of Team Foundation Server 2008 for a client. Before setting off, I tried to make sure that all the prerequisites were in place - i.e. that there was a suitably-specced server available for use, which was connected to the domain, that all the necessary service accounts were created, and firewall ports opened, etc.

So, I kicked myself somewhat on arrival when I realised that the server was running a 64-bit OS, and remembered that the application tier of TFS only supports 32-bit. Doh! This blog entry is partly intended to prevent me from ever forgetting that again.

However, it all turned out fine in the end. There were other reasons why I didn't relish the prospect of installing TFS on the box in question - namely that it was also being used as a domain controller and SQL Server (this isn't as bad as it sounds - the server exists solely to provide an R&D development environment for a new project with demanding timescales). So, the solution I opted for was to install Virtual Server 2005 R2, and then install TFS on a virtual machine running a 32-bit OS. This worked well, as the host server was massively over-specced for the tasks at hand.

I think virtualization is a technology whose time has really come, it certainly makes it very easy to set up development environments like this one, where the number of servers required exceeds the number of physical servers available. Occasionally I come across posts on the web from people who're trying to install, say, TFS, SQL Server, SharePoint, and Exchange all on the same server, and getting into a pickle. Don't do it. Embrace virtualization. Developers know all about separation of concerns when designing software solutions - try the equivalent approach when configuring your development servers.

As an aside - the team chose to use Conchango's SCRUM for Team System process template, which seems to work very well, and I recommend it for anyone running a project using the SCRUM methodology. Remember, TFS is process-agnostic, you're not limited to using MSF.

Finally, a great book about Team Foundation Server which I'm happy to recommend to developers:

I've read plenty of TFS / Team System books from the project management and agile methodology viewpoints, but this is the first one I've come across that I think really sells TFS to developers.

The first part of the book introduces TFS and software development processes in general, before exploring the improvements in TFS 2008, and introducing VSTS 2008 Database Edition.

Preamble over, the main meat of the book goes deep into the key developer-centric areas of version control and Team Build, where TFS can really improve the quality of life of the average developer! There's lots of detail on branching models, and explaining best practice solutions to questions such as how to share code between team projects. It's not all dry theory though, there is plenty of code on show as the author explains some potential customizations and uses for the TFS API.

This is continued in the last two chapters, which dig into administration, customization, and using Workflow Foundation with TFS.

All in all, a really good read, which goes some way to highlighting the awesome power of Team Foundation Server.

Amazon - Team Foundation Server 2008 In Action

I’m currently enjoying setting up a Greenfield implementation of Team Foundation Server 2008 for a new client, and getting the development and test teams up to speed on TFVC, work item tracking, continuous integration, and all that groovy agile stuff that Team System make so easy.

After six months away from TFS, it’s nice to get reacquainted with my old friend, and realise that the product has come a long way since the original 2005 release.

I’m delighted to see that MS have continued their tradition of releasing frequent enhancements as a pack of downloadable “Power Tools”, one of the coolest of which is the Build Notification Tool.

When running, an icon will appear in your system tray which looks something like this (the symbol within the circle will differ depending on the current status of the builds being monitored):

Right-clicking on the icon and selecting options allows you to specify the builds and the events in which you’re interested:

Having done that, you’ll get toast popping up above your system tray when any of the specified events occur. Also, the icon changes accordingly.

Here’s what it looks like when a build starts. Note the hyperlink to stop the build if desired:

When a build is successful, the toast includes hyperlinks to view the associated work items, or open the build drop location:

If When a build breaks, the toast includes a hyperlink to the associated changesets, and the icon turns into a red cross:

At any time, you can right-click on the Build Notification icon and select “View Build Status” to get a summary of the current status of all the builds in which you’ve expressed interest:

It really is quite neat, and I prefer this approach to subscribing to the automated build event emails, which I tend to overlook.

One of the features that the current version of Team Foundation Server doesn’t offer is the ability to Get Latest Version on Checkout.

If you’ve ever checked something out, made copious changes, gone to check it back in and then realised you’ve been developing on a woefully outdated file/project/solution (and had to perform a lengthy merge operation), you’ll know how useful this facility could be.

Well, this feature is coming in the VS Orcas release, but Microsoft Israel have developed a free add-in to add this functionality to VS Whidbey:

http://blogs.microsoft.co.il/files/folders/leon/entry10828.aspx

This will add a “TFS GetLatest Configuration” option to the top of the Tools menu (with a tacky smiley face icon ).

Great news for all users of Team Foundation Server:

"Microsoft Corporation is excited to announce the acquisition of devBiz Business Solutions, makers of TeamPlain Web Access, a web interface for Team Foundation Server that allows managing work items, documents, reports, and source control repositories."

http://www.devbiz.com/acquisition.aspx 

One of the top items on our team's wishlist for TFS was a web-based interface to allow business users to view and amend work items without needing to install Visual Studio, and it seems that our wishes have been granted:

Product Roadmap

• TeamPlain Web Access is now available as a free download to all Team Foundation Server customers.
  
  
• TeamPlain Web Access will be re-released as Team System Web Access as part of the Team Foundation Server Power Tools.
  
  
• Team System Web Access will be fully integrated into a future version of Visual Studio Team System.

 Woohoo!

Here's a great article from Eric Lee highlighting some more new features in Visual Studio Orcas.  Some of these are already available as TFS Powertoys.  Others aren't, and I can't wait to get my hands on them, most notably the TFS Build Definition Editor (which might have reduced a little bit of the pain I experienced earlier this week! :-)
Also Build Retention Policies and Continuous Builds will be much-welcomed features.  Team Foundation Server 1.0 is a fantastic product, probably the most useful for the average development team that MS have released in many a long year, but it looks like  the next release will really build (sorry) on that foundation (sorry again) to make a more fully-featured system.  So, when's the release date...?

Update 16 July 2008 - this post has been receiving an increased amount of pageviews in recent months, which is nice, but I should point out that it no longer reflects my thinking on how best to structure a TFS source tree. Having lived with the structure described below for several months, and a few project iterations, it became apparent that having only one (shared) copy of common class libraries sometimes made it impossible to build bugfix releases of applications if the common libraries on which they depended had subsequently changed. I'm now sold on the branch and merge philosophy.and heartily recommend reading Eric Sink's excellent Source Control HOWTO guide for more information about SCC best practices.

That caveat aside, the post below may still contain some useful information if you really want to do this, or are struggling with some similar MSBuild-related scenario!

---

I returned to work after Tuesday's MSDN Roadshow fired up and full of ideas, eager to try out ASP.NET AJAX in anger, and start playing with LINQ on my VS Orcas VPC.  But before all that, I was determined to improve our source control practices and end the branching madness which has become the one downside of using Visual Studio Team Foundation Server.

Like any good development team, we don't believe in reinventing the wheel or duplicating code.  So naturally we have a set of shared class libraries which contain business logic and object models which are common to multiple applications.  Also, we make use of the MS Enterprise Library, and other third party assemblies such as Wintellect PowerCollections.

Now, what I wanted to achieve was this:

1. Share our common code across multiple (ASP.NET) applications, without resorting to branching between TFS projects (which has in the past led to multiple versions of the shared codebase getting out of sync with each other).
2. Also share the third-party DLLs, again without branching.
3. Create Team Builds for each application which will automatically get the latest versions of the shared class libraries and third-party assemblies.

That doesn't sound like a lot to ask for, does it?  But it was surprisingly difficult to achieve - in fact it took me eighty-one attempted builds before I got the desired effect!  So, before I forget how I achieved it, and in case there's anyone else out there trying to do the same thing, let me explain all...

The first thing to do is sort out your source control tree structure, and ensure that all developers in the team are mapping onto their local workspace in the same way (otherwise you'll get into problems with different relative paths to references).
We have a TFS Team Project for each application, then place the solution within a "trunk" folder - this makes it much easier to branch the application at a later date (for example, when you want to start developing a major new version whilst still making smaller bugfix releases to the current live version).
Then, we have a separate Team Project called "Shared Resources", within which is a folder for our class libraries, and another folder for third-party binaries.
So, our tree looks something like this:

$
|-WebApp1
| |-Trunk
| |-VersionX
|-SharedResources
  |-Binaries
  | |-Microsoft
  | | |-EnterpriseLibrary
  | |-Wintellect
  |   |-PowerCollections
  |-ClassLibraries
    |-CommonUtilities
    |-CommonBusinessLogic

You get the idea.  This step was straightforward enough.

The next trick is to use Web Application Projects rather than web sites.  This alternative web project model (which is similar to the model used in VS2003) was released as an optional add-on to VS2005 shortly after its release, and has been baked into VS2005 Service Pack 1, so if all developers on the team are fully patched, there should be no problems with using this project model.  It's required because in this model, all assembly references are defined within a project file (no such project file exists in the standard VS2005 web project model).  This allows us to define a reference to shared third-party binaries which will be recognised by MSBuild.

Scott Guthrie has written a tutorial on upgrading VS2005 Web Site Projects to be VS2005 Web Application Projects, which may come in useful at this point.  It's pretty straightforward, if a little tedious (especially if your existing site has many pages and controls, which you wish to wrap in namespaces).

The suite of shared class libraries should be given its own solution.  For each class library project, add a post-build event to copy its output to a \binaries folder (thanks to this blog post from Vertigo Software for highlighting this crucial step).  The command line required is:

xcopy /Y /S /F "$(TargetPath)" "$(SolutionDir)binaries\"

Our web application projects should then reference these compiled binaries as required, with CopyLocal set to true.  This is vital for the Team Build to work - if project references are used for assemblies belonging to different team projects you'll have no joy.  The downside of this for the development team is that they have to Get Latest Version and recompile the shared class libraries periodically to pick up any changes made by coworkers.  But I think that is more straightforward than if the shared libraries had been branched (so periodic merging would be necessary), and at least with this set-up the automated builds (which we are now in a position to create) will perform a full integration and flag up any issues.  It's just one more good reason to set up scheduled builds :-)

So, at this point I've achieved goals (1) and (2) - eliminated branching of shared class libraries and third party assemblies, and everything is building just fine on the desktop.  Now comes the tricky bit - getting it to work on the build server through MSBuild.  In the dying years of the last century I spent my days coding Assembler on IBM mainframes, and I have to say that the trial-and-error of MSBuild reminds me somewhat of creating JCL (Job Control Langauge) scripts in those dark days!  Fortunately I had this excellent article by Manish Agarwal on which to base my build - he explains in great detail how to persuade MSBuild to first compile the shared assemblies, then the client application, and I encourage you to go check out his post and the other tips on his site.  The only additional step I needed to add was a Get of the third-party binaries.

To cut a long story short, here's how my override of the "BeforeGet" target ended up looking: 

<!-- This task executes prior to Getting the sources -->
  <Target Name="BeforeGet">
    
    <!-- BEGIN GETTING COMPILED THIRD-PARTY BINARIES -->
    <!-- delete default workspace -->
    <DeleteWorkspaceTask
    TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
    Name="$(WorkspaceName)" />
    
    <!-- delete any temporary workspace from last time -->
    <DeleteWorkspaceTask
TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
Name="$(WorkspaceName) SR" />
    <!-- make some directories-->
    <Exec WorkingDirectory="$(SolutionRoot)" Command="mkdir 
          SharedResources" />
    <Exec WorkingDirectory="$(SolutionRoot)/SharedResources" 
          Command="mkdir Binaries" />
    <!-- make a temporary workspace -->
    <Exec 
      WorkingDirectory="$(SolutionRoot)/SharedResources/Binaries"
      Command=""$(TfCommand)" workspace /
        new "$(WorkspaceName) SR" 
        /server:$(TeamFoundationServerUrl)" />
   
    <!-- map the workspace to our local folder -->
    <Exec
      WorkingDirectory="$(SolutionRoot)"
      Command=""$(TfCommand)" workfold 
        /map "/workspace:$(WorkSpaceName) SR" 
        /server:$(TeamFoundationServerUrl) 
        "$/SharedResources/Binaries" 
        "$(SolutionRoot)\SharedResources\Binaries""/>
    <!-- get the binaries -->
    <Exec 
      WorkingDirectory="$(SolutionRoot)/SharedResources/Binaries"
      Command=""$(TfCommand)" get " />
    <!-- be tidy and delete the temporary workspace -->
    <DeleteWorkspaceTask
TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
Name="$(WorkspaceName) SR" />
    <!-- END GETTING COMPILED THIRD-PARTY BINARIES -->
    
    
    <!-- BEGIN MAPPING WORKSPACES FOR EACH TEAM PROJECT -->
    <!-- delete default workspace -->
    <DeleteWorkspaceTask
    TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
    Name="$(WorkspaceName)" />
    <!-- create new workspace -->
    <Exec
      WorkingDirectory="$(SolutionRoot)"
      Command=""$(TfCommand)" workspace 
        /new "$(WorkspaceName)" 
        /server:$(TeamFoundationServerUrl)"/>
    <!-- remove default mapping -->
    <Exec
     WorkingDirectory="$(SolutionRoot)"
     Command=""$(TfCommand)" workfold 
       /unmap "/workspace:$(WorkSpaceName)" 
       "$(SolutionRoot)""/>
    <!-- add desired mapping (see itemgroup maps below) -->
    <Exec
      WorkingDirectory="$(SolutionRoot)"
      Command=""$(TfCommand)" workfold 
        /map "/workspace:$(WorkSpaceName)" 
        /server:$(TeamFoundationServerUrl) 
        "%(Map.Identity)" "%(Map.LocalPath)""/>
    <!-- END MAPPING WORKSPACES FOR EACH TEAM PROJECT -->
  </Target>

Whilst my folder mappings and SolutionsToBuild item groups look like this:

<!-- herewith all the solutions we want compiling - shared libs first -->
  <ItemGroup>
    <SolutionToBuild 
      Include="$(SolutionRoot)\SharedResources\ClassLibraries\Libs.sln" />
    <SolutionToBuild 
      Include="$(SolutionRoot)\WebApp1\WebApp1.sln" />
  </ItemGroup>

  <!-- Describes a mapping between team projects and local folders -->
  <ItemGroup>
    <Map Include="$/SharedResources/ClassLibraries/">
      <LocalPath>$(SolutionRoot)\SharedResources\ClassLibraries</LocalPath>
    </Map>
    <Map Include="$/WebApp1">
      <LocalPath>$(SolutionRoot)\WebApp1</LocalPath>
    </Map>
  </ItemGroup>

Voila!  After much hair-pulling and cursing, I had achieved my three goals and facilitated truly shared code and binaries across multiple TFS team projects, with automated Team Builds for all applications.  As a result our solutions open and compile faster (because they don't include the shared libraries), our overnight application builds always include the latest copy of shared libraries (and hence highlight any integration issues), and most importantly we don't have to mess about with periodic merging of branched libraries.

While I'm on the subject of Team Foundation Server, here's an incredibly useful download from Noah Coad - a Team System add-in to allow searching of work items - very useful if you have as many outstanding tasks as I currently do :-)

It's still February (just!), but the March CTP of Visual Studio "Orcas" has been released.

You can download the installable bits here, alternatively you can download a Virtual PC image here.  The latter is my preferred method for playing with these regular preview releases, as it provides a ready-configured Windows PC with Visual Studio, TFS and all the bits, which is surely far better than wasting time configuring a development box or VPC oneself, then having to repeat the task a month later.

Of course, the downside to this approach is the increased download size, which means my desktop currently looks like this:

 

Rick LePlante reports that a preview of VS Team System is now available for download to MSDN subscribers.  I've been desperate to try this, but at 3.39Gb this download could take me a while, and if it's anything like the beta 2 of SQL Server 2005 I suspect I'll discover that my aging PCs don't have sufficient power to run it.  Ah, the relentless march of progress...