# Friday, 10 July 2015

Are you adopting TFS 2013, 2015 or even Visual Studio Online?

Do you need to train a lot of staff members with different roles?  eg. developers, testers, scrum masters, product owners, stakeholders.

Is it difficult to allow team members to be out of the office for 2, 3 or 5 consecutive days at a training course.

RippleRock can customise a flexible TFS training course to suit you and if required combine it with consultancy, coaching and certification (eg. Certified Scrum Master, Certified Product Owner).

We typically deliver training onsite and configure the agenda and schedule to suit your requirements meaning it is a much more cost effective of training the right people on the right topics.

RippleRock are a Microsoft Gold Application Lifecycle Management Partner and our trainers are ALM Consultants with Microsoft Certified Solution Developer: Application Lifecycle Management

officiallogo     mcsd

As an example of potential topics:

Introduction and overview
  • What is Application Lifecycle Management?
  • What is Team Foundation Server?
  • Visual Studio Tools line up
  • Process Templates & Work Items
  • Choosing a Process Template
  • Understanding Team Projects & Project Collections
  • Client Access and Tools
  • Scrum Process re-cap
  • The Visual Studio Scrum Process Template
TFS Architecture & administration
  • Planning a TFS  Deployment
  • Installing Team Foundation Server
  • Migration/Upgrade considerations
  • TFS Administration Console
  • Setting up SMTP & Email Alerts
  • Monitoring Server Health
  • Backup and Restore
  • Administration via Command Line and PowerShell
  • TFS Security and Permissions
  • Rebuilding the TFS data warehouse and adding reports
Agile Planning
  • Agile Portfolio Management
  • Gathering requirements, estimation and prioritisation
  • PowerPoint Storyboarding
  • Backlog maintenance
  • Forecasting and release planning
  • Sprint Planning
  • Capacity Planning
  • Agile Boards (Task & Kanban)
  • Working with Teams
  • Team Rooms
  • Work Item Queries
  • Work Item Charting
  • Team Web Access Reporting
  • Stakeholder feedback
Agile Development
Visual Studio & Team Explorer   
  • My Work
  • Suspend/Resume
  • Code Reviews
  • Code Metrics
  • Code Clone Analysis
  • Unit Testing and code coverage
Team Explorer Everywhere
  • Cross platform version control
  • Automating builds with Nant or Maven
Version Control Basics
  • Choosing a Version Control System
    • Team Foundation Version Control Vs. Git
  • Version Control Settings
  • Check-in policies
  • Check-in notes
  • File types
  • Workspaces
    • Server Vs. Local
  • Check-in/out
  • Changesets
  • Shelving
Advanced Version Control
  • Branching & Merging
    • Branching Strategies
    • Branch Visualisation
    • Dealing with Conflicts
  • Viewing version control history
  • Rolling back code changes
  • Securing version control
  • Using custom difference and merge tools
  • Command line version control
  • Git fundamentals
Automated build introduction
  • Team Foundation Server Build architecture
  • Creating a build definition
  • Build triggers
    • Continuous Integration
    • Scheduled Builds
    • Gated Check-ins
  • Editing Build Parameters
  • Including unit tests in your build process
  • Queuing a build
  • Private Builds
Customising automated builds
  • Process customisation
  • Using 3rd Party components
  • Including PowerShell scripts
  • Versioning Assemblies
  • Cloning a build
  • Comparing Build Definitions with tfpt.exe
Agile Testing
  • Overview of test tools in Visual Studio
  • Microsoft Test Manager
    • Test Plans/Suites/Cases
    • Microsoft Test Runner
    • Exploratory Testing
  • Web Based Test Manager
  • Automated Tests (CodedUI) inc. cross browser
  • Microsoft Lab Management
  • Web Performance Test and Load Test
Microsoft Release Manager
  • Release Manager Overview and architecture
  • Licensing Release Manager
  • Integrating Release Manager with your build process
  • Creating a release
  • Using PowerShell Desired State Configuration
Team Foundation Server Reporting
  • How data flows through TFS
  • Out-of-the-box TFS reports
  • Team Web Access Reports
  • Work Item Charting
  • Work Item Reporting
  • Custom Excel Reporting
  • Custom SSRS Report
Customising Team Foundation Server
  • Understanding Process templates
  • Editing Process Templates
    • Process Template Editor
    • Witadmin.exe
  • Customising and creating Work Items
  • Working with Global Lists
  • Tailoring Agile Portfolio functionality
  • Editing the Team process
  • 3rd Party Tools and controls
  • Using the TFS API
  • PowerShell with TFS

Contact us to discuss your requirements and build a personalised training plan.

Richard



.

Friday, 10 July 2015 10:39:46 (GMT Daylight Time, UTC+01:00)  #    Comments [0]


# Wednesday, 08 July 2015

There are some great features coming in Team Foundation Server 2015 and they’re already largely available in Visual Studio online. 

My personal favourite is the enhanced Agile tooling in Team Web Access and in particular the improved support for Kanban (swimlanes, explicit policies etc.).  However, I love the new simplified build system and its tight integration with test and release.  Release Management is also ready for the big time with cross platform support and a new web client.

TFS 2015 is due for release on 20th July and there are a lot of reasons you should think about upgrading.  In addition, editable process templates are coming to Visual Studio Online so you might also be thinking about a move to the cloud.

However, do you find yourself running TFS 2010 or TFS 2012 (even 2005 or 2008 if you’re really unlucky) and now you’re one more version behind which can be a problem for supportability?

Maybe you have a heavily customised process template or you’re using Scrum For Team System and you want to change it as part of the upgrade?

If you need some help and advice on the options open to you then drop us a line. 

We can help assess your situation and leave it to you from there or take care of the whole upgrade process and follow up with training and coaching.  We’ll tailor any engagement to suit your requirements.

Richard



.

Wednesday, 08 July 2015 21:08:30 (GMT Daylight Time, UTC+01:00)  #    Comments [0]


# Friday, 06 February 2015

I was working on a client’s computer yesterday to make some Process Template changes on TFS 2013.  I fired up a command prompt, typed witadmin /? to see if it was on the path an off I went.

I exported a Work Item definition (witadmin exportwitd), added a field and tried to import the changes (witadmin importwitd).  I then received a couple of schema validation errors along the lines of:

TF212019: Work item tracking schema validation error at row x, column y: The HideControlBorders attribute is not declared.

TF212019: Work item tracking schema validation error at row x, column y: The HideReadOnlyEmptyFields attribute is not declared.

I checked my changes, and checked that the attributes were present.

<FORM>
     <Layout HideControlBorders="true" HideReadOnlyEmptyFields="true">
     …

It wasn’t one I’d seen before, the changes imported correctly on my own VM and there were no hits on a quick web search (hence I’m writing this blog!)

I know those attributes were added in TFS 2012 and that should have given me a clue as to what was causing the problem but instead I wasted time investigating other causes.

It wasn’t until I made a change to the categories.xml that it became obvious.  Again, export was fine but an import gave a more useful error message about my version of witadmin.

Doh!  I quickly checked and the client had both VS2013 and VS2010 installed so the wrong version of witadmin.exe was on his path.  It wasn’t my machine to mess with so I just did a quick cd to:

C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE

I hit the same witadmin importwitd and everything was fine.

Cheers,

Richard



.

Friday, 06 February 2015 10:35:31 (GMT Standard Time, UTC+00:00)  #    Comments [0]


# Friday, 14 November 2014

I use a local TFS 2013 HyperV image for most of my demos and experimentation and so reasonably frequently I break it and just rollback to a snapshot rather than spending time trying to repair it.

This week I wanted to keep some work on there but I’d also broken a collection (on purpose) so my plan was to delete the collection and re-create it (I could have just created a new one but I liked the succinctly named TrainingCollection!)  

These are the steps I followed

  • Launched the TFS Admin tool and detached TrainingCollection
  • Opened SQL Server Management Studio and deleted the Tfs_TrainingCollection database
  • Created a new collection called TrainingCollection using TFS Admin

I then created a Team Project and it failed at the Reporting Services stage because a TrainingCollection folder already existed.  Oops. 

image

I tried creating the Team project and it failed again, so I had a look in the build creation log

---begin Exception entry---

Module: Engine

Event Description: TF30162: Task "WITs" from Group "WorkItemTracking" failed

Exception Type: Microsoft.TeamFoundation.Client.PcwException

Exception Message: TF24016: Cannot find team project 'CustomerTraining'.

--- end Exception entry ---

I realised that I had confused Visual Studio with all my messing around so the way forward was to delete the local TFS Cache so that Visual Studio could forget about the old collection and get to know the new one.

  • Closed Visual Studio
  • Navigated to my cache folder and deleted the contents.  

For my installation it was here:

C:\Users\<MyUser>\AppData\Local\Microsoft\Team Foundation\5.0\Cache

Obviously, it’ll be slightly different if you’re targeting another version of TFS or if you have installed VS on another drive.

I re-opened Visual Studio and created my Team Project with no further issues. 

I don’t suppose this is something you’re likely to run into in a production TFS environment but  you never know!

Cheers,

Richard



.

Friday, 14 November 2014 12:14:15 (GMT Standard Time, UTC+00:00)  #    Comments [0]


# Thursday, 06 November 2014

Final post for tonight and then I might have a little nap on the train.

On another recently created project utilising the custom Team field to scope Work Items to TFS teams rather than the Area Path I encountered another minor issue.

I created a Test Plan using Microsoft Test Manager and then clicked the Open in Web Access button

image

I received the following error in Team Web Access:

The test plan with id XX does not exist or it’s area path is not owned by the default project team.  Include it in the default project team’s owned areas and try again.

image

The error is a little cryptic as I hadn’t even started adding area paths, much less locking them down.  It was in fact, another symptom of using the custom Team field,

I hadn’t implemented the template customisation and so the Work Item definition was missing the following on the Team field:

<DEFAULT from="value" value="Unassigned" />

TFS 2013 Update 3 requires that you add your Team field to the new Test Plan Work item.  You don’t have to expose the field on the UI but it must have a default value or you will hit issues in Team Web Access when accessing those Test Plans that do not have the field populated.

Easy to resolve –

  • Run a query into Excel that brings back all the Test Plan Work Items
  • Add the Team field to the list of columns
  • Set the Team value for the Test Plans to Unassigned (or whatever you use)
  • Use witadmin.exe or the Process Template Editor to update your Work Item definitions to have a default Team value

Time for a snooze.

Cheers,

Richard



.

Thursday, 06 November 2014 20:00:00 (GMT Standard Time, UTC+00:00)  #    Comments [0]


If you made it through my last post, you’ll know that I recently updated a TFS 2013 RTM install to Update 2 to resolve a bug in TFS. 

During the update we have to re-apply service accounts and confirm servers etc.  At one stage we were prompted for the SQL Reporting Services Server and the reporting service password.  The issue we needed to resolve was holding up work and unfortunately we couldn’t locate the SSRS password that we needed.  I asked which was more important – getting the team working again or running reports.  The answer was obviously the former and so we took the decision to skip Reporting Services safe in the knowledge that we could deal with it later as a non-critical issue.

The next day the TFS admin had all the details he needed to re-enable reporting and got stuck into the TFS Admin Console.

MSDN: TFS 2013 - Add a report server

Edit the information to configure reporting

However, he added the server details for the data warehouse, clicked Test Connection and received the following error:

The database you specified cannot be used. The database exists, but its schema is not valid for use with Team Foundation Server.

The obvious reason for the error was that the TFS update had changed the data warehouse schema and now our existing warehouse database was out of date.

I wondered if we could update the warehouse database individually but if you understand the reporting architecture in TFS (read my other blog post if you don’t) then you’ll know that we could just blow away the existing warehouse and re-create it.  So that’s what we did, we now have the imaginatively named Tfs_Warehouse2 and Tfs_Analysis2 databases.  We hooked up reporting again, rebuilt the warehouse using the Admin Console and Bob’s your uncle.

We hit a minor snag later that the analysis database didn’t seem to have reflected the changes so we called the ProcessWarehouse web service followed by the ProcessAnalysisDatabase web service, checked everything completed successfully with the GetProcessingStatus web service (details here) and everything was working again in time for tea and biscuits!

I later found an old TFS 2010 related blog post that confirmed what had happened and that our resolution was correct.  Hurrah!

60 minutes left, let’s go for the hat-trick.

Cheers,

Richard



.

Thursday, 06 November 2014 19:30:00 (GMT Standard Time, UTC+00:00)  #    Comments [0]


My blog posts are like really terrible buses, you wait 8 weeks for one and now I’ve finally got a little time (3 hours on a train home from the midlands) so 2 or 3 are going to arrive at once.

A process template customisation I do regularly for customers is adding a Team field to scope Work Items to teams in TFS 2012 and TFS 2013.  Microsoft have detailed the process here so it’s not a particularly controversial thing to do and I believe it provides a better experience when you have multiple teams working against a central backlog.

I blogged recently about how to use PowerShell to automate the process of adding a team field.

I performed the customisation for three companies in the last couple of months and bumped into a some issues with Team Web Access in particular.  Even though adding a Team field is very much a valid thing to do, there can be a couple of wrinkles to iron out.

The first issue came as a bit of a shock.  The background to the problem is this - a customer has been happily using TFS 2013 on a pathfinder project with a single team.  Things have gone well and so they wish to roll out the tool to about 5 other teams.

We worked together to create a slightly customised process template which added some further hierarchy to the standard Visual Studio Scrum 2013 process template.  Without thinking, I started work using a Visual Studio Scrum 2013.3 template and when I tried to upload it to the customer’s server we had some errors as Update 3 added all sorts of test related artefacts that weren’t available with the customer’s TFS 2013 RTM version. 

That wasn’t the issue, however and I quickly made the changes to an RTM version of the VS Scrum template and uploaded it successfully.  We then created a central project to house the company’s portfolio backlog (I must add that to my things to blog about!).

We were to resume working on the new project a few days later but before then I received a frantic email from the pathfinder team saying that whenever they tried to edit an existing Work Item using the Team Web Access client they received the following error:

Team Foundation Error

The server operation failed, (Value cannot be null. Parameter name:key).

I quizzed the team on whether they had changed anything on the pathfinder project as templates are like cookie cutters, once you cut out the cookie, it doesn’t matter what you do to the cutter, it doesn’t effect the cookies you produced previously.

I went onsite and pulled down the processconfiguration.xml, categories.xml and the Work Item definitions for the pathfinder project.  Nothing had changed!

Some experimentation confirmed that uploading a new process template configured to use a custom team field had broken Team Web Access for an existing project.  Clearly that shouldn’t happen and although I we could have battled through and fixed it we took the decision to update the TFS 2013 RTM server (without knowing for sure that Update 2/3/4 had fixed the problem).  We took the decision to go with Update 2 as we weren’t quite ready for the new test artefacts and I’d recently been badly burned by an issue with Update 3 massively inflating the collection database (another thing to add to my list of blog posts to write).

The upgrade to Update 2 only caused us a short period of downtime and it was something we were planning on doing soon anyway.  The problem was resolved immediately so it was obviously a known bug which was addressed in the first update for TFS 2013 (there was no update 1 for TFS 2013).

A similar but not identical issue is discussed in the MSDN forum post here.

There are still 90 minutes left of my train journey so I may as well write up the next instalment.

Cheers,

Richard



.

Thursday, 06 November 2014 19:00:00 (GMT Standard Time, UTC+00:00)  #    Comments [0]


# Friday, 12 September 2014

One of the Team Foundation Server Process Template customisations I do frequently is changing a project to make use of a custom team field rather than the default Area Path to scope Work Items to teams.

If you haven’t made use of teams in TFS 2012 or TFS 2013 yet then check out these links

Multiple Teams with Microsoft Team Foundation Server 2012 & Visual Studio Scrum

TFS 2013: Collaborate using team resources

If you don’t know what is involved in customisation then you need to check out this page.

Customize a team project to support team fields

Now, you can, as with any process update, make changes offline and any subsequent projects created using that template will see the changes.  Or, you can update an existing in-flight project with template changes. 

It’s not particularly difficult to change your template to make use of a team field but it is time consuming so I wrote a PowerShell script to do it both to save me time and to play around with using PowerShell to do XML transformations.

My script downloads the required files from a Visual Studio Scrum 2013 project, backs them up, performs an XML Transform on them and uploads them to your project.  If you are using a different process template then you will need to edit the XML transforms and the selected Work Item definitions but the technique is the same.

You can call the script Add-Teams.ps1 from the command line and provide 3 parameters

Add-Teams.ps1 “http://TFS2013:8080/tfs/DefaultCollection” MyProject “C:\TemplateUpdates”

Defaults are specified at the beginning of the script so if you plan to run it using PowerShell ISE for example, then simply change the values.

        #TFS Collection Url
        [string]$CollectionUrl =          "http://TFS2013:8080/tfs/DefaultCollection",
        #Name of the TFS Team Project to transform
        [string]$TeamProjectName =        "MyProject",
        #Working folder to store the XML transforms, downloaded files and backup
        [string]$WorkingFolder =          "C:\TemplateUpdates" 

There is some (hopefully) useful logging throughout the script which uses write-verbose, so if you want to turn it on then  give the script a –verbose flag when you run it.

The script

First we create a function called Transform-XML that takes an XML file and a transform file to apply.  We’ll use it to alter the Work Item definitions, the Process Configuration and add a Global List.


function Transform-XML 
{
     Param (
            [Parameter(Mandatory=$True)][ValidateNotNull()]$Wit,
            [Parameter(Mandatory=$True)][ValidateNotNull()]$Tfm
        )


Next, the necessary Work Item definitions (Product Backlog Item, Task, Bug, Feature & Test Plan) are downloaded from your project using WitAdmin.exe (usually found in C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\Witadmin.exe)


# Export Work Item definitions 
write-Verbose "Exporting PBI definition"
& $WitAdmin exportwitd /collection:$CollectionUrl /p:$TeamProjectName /f:$PBIDefinition /n:"Product Backlog Item"
write-Verbose "Exporting Task definition"
& $WitAdmin exportwitd /collection:$CollectionUrl /p:$TeamProjectName /f:$TaskDefinition /n:"Task"
write-Verbose "Exporting Bug definition"
& $WitAdmin exportwitd /collection:$CollectionUrl /p:$TeamProjectName /f:$BugDefinition /n:"Bug"
write-Verbose "Exporting Feature definition"
& $WitAdmin exportwitd /collection:$CollectionUrl /p:$TeamProjectName /f:$FeatureDefinition /n:"Feature"
# Required if using TFS 2013 Update 3 or later 
write-Verbose "Exporting Test Plan definition"
& $WitAdmin exportwitd /collection:$CollectionUrl /p:$TeamProjectName /f:$TestPlanDefinition /n:"Test Plan"

# Export Process Configuration
write-Verbose "Exporting Process Configuration"
& $WitAdmin exportprocessconfig /collection:$CollectionUrl /p:$TeamProjectName /f:$PCDefinition 

# Export Global List 
write-Verbose "Exporting Global List"
& $witadmin exportgloballist /collection:$CollectionUrl /f:$GLDefinition 

The we copy all the downloaded files into a backup directory.  If your Team project was called MyProject then all the files would be downloaded to C:\TemplateUpdates\MyProject and a backup would be copied to C:\TemplateUpdates\MyProjectBackup\110914.161115 where the date is 11\09\2014 and the time is 16:11 and 15 seconds.  This way, if anything goes wrong, you have your original files to upload.


# Create backup of process files 
write-Verbose "Backing up process files"
$timestamp = Get-Date -UFormat "%d%m%y.%T" | foreach {$_ -replace ":", ""}

Copy-Item -Path $ProjectFolder -Container -Destination "$($ProjectFolder)Backup\$timestamp" -Recurse -force

After that we call the Transform-XML function against the required files

try
{
    #Try transforming the required files and exit the script if there are any problems
    
    # Add Global List 
    write-Verbose "Adding Team Global List"
    Transform-XML $GLDefinition $GLTransform

    # Update Work Item Definitions to add new Team field and include on form 
    write-Verbose "Updating PBI Definition"
    Transform-XML $PBIDefinition $WITTransform
    write-Verbose "Updating Task Definition"
    Transform-XML $TaskDefinition $WITTransform
    write-Verbose "Updating Bug Definition"
    Transform-XML $BugDefinition $WITTransform
    write-Verbose "Updating Feature Definition"
    Transform-XML $FeatureDefinition $WITTransform
    # Required if using TFS 2013 Update 3 or later
    write-Verbose "Updating Test Plan Definition"
    Transform-XML $TestPlanDefinition $WITTransform

    # Update Process Template to make use of new Team field instead of AreaPath 
    write-Verbose "Updating Process Configuration"
    Transform-XML $PCDefinition $PCTransform
}

The XML transform for a Work Item looks like this for example


<?xml version="1.0"?>
<witd:WITD xmlns:witd="http://schemas.microsoft.com/VisualStudio/2008/workitemtracking/typedef" xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
  <WORKITEMTYPE name="Bug">
    <FIELDS>
    <!-- If the team field has already been added then remove it first-->
    <FIELD name="Team" xdt:Transform="Remove"  xdt:Locator="Match(name)" />
      <FIELD name="Team" refname="RippleRock.Scrum.Team" type="String" reportable="dimension" xdt:Transform="Insert">
        <HELPTEXT>Name of the team that will do the work.</HELPTEXT>
        <ALLOWEXISTINGVALUE />
        <ALLOWEDVALUES >
          <GLOBALLIST name="Teams" />
        </ALLOWEDVALUES >
        <DEFAULT from="value" value="Unassigned" />
      </FIELD>
    </FIELDS>
    <FORM>
      <Layout>
      <Group>
      <Column>
        <Group Label="Status">
          <Column PercentWidth="100">
          <!-- If the team field has already been added then remove it first-->
            <Control FieldName="RippleRock.Scrum.Team" xdt:Transform="Remove"  xdt:Locator="Match(FieldName)" />
            <Control FieldName="RippleRock.Scrum.Team" Type="FieldControl" Label="Team" LabelPosition="Left" EmptyText="&lt;None&gt;" xdt:Transform="Insert" />
          </Column>
        </Group>
        </Column>
        </Group>
      </Layout>
    </FORM>
  </WORKITEMTYPE>
</witd:WITD>


This adds a field called RippleRock.Scrum.Team to the Work Item and then adds a Field Control at the end of the Status group on the Work Item form.  I added an additional Remove transform for both elements so that if you run the script against an item that already has a Team field then it will be replaced.

Finally, we import all our definitions and we should be good to go.


# Import Global List 
write-Verbose "Importing Global List"
& $witadmin importgloballist /collection:$CollectionUrl /f:"$ProjectFolder\GlobalList.xml"

# Import Work Item definitions 
write-Verbose "Importing PBI definition"
& $WitAdmin importwitd /collection:$CollectionUrl /p:$TeamProjectName /f:"$ProjectFolder\WorkItem Tracking\TypeDefinitions\ProductBacklogItem.xml" 
write-Verbose "Importing Task definition"
& $WitAdmin importwitd /collection:$CollectionUrl /p:$TeamProjectName /f:"$ProjectFolder\WorkItem Tracking\TypeDefinitions\Task.xml" 
write-Verbose "Importing Bug definition"
& $WitAdmin importwitd /collection:$CollectionUrl /p:$TeamProjectName /f:"$ProjectFolder\WorkItem Tracking\TypeDefinitions\Bug.xml" 
write-Verbose "Importing Feature definition"
& $WitAdmin importwitd /collection:$CollectionUrl /p:$TeamProjectName /f:"$ProjectFolder\WorkItem Tracking\TypeDefinitions\Feature.xml" 
# Required if using TFS 2013 Update 3 or later
write-Verbose "Importing Test Plan definition"
& $WitAdmin importwitd /collection:$CollectionUrl /p:$TeamProjectName /f:"$ProjectFolder\WorkItem Tracking\TypeDefinitions\TestPlan.xml"

# Import Process Configuration 
write-Verbose "Importing Process Configuration"
& $WitAdmin importprocessconfig /collection:$CollectionUrl /p:$TeamProjectName /f:"$ProjectFolder\WorkItem Tracking\Process\ProcessConfiguration.xml"


Remember to follow the steps in the “Configure Team Settings” section of the Customize a team project to support team fields to alter how Work Items show up on the team backlogs.

image

Download the script and the transforms here.

I hope it saves you some time.

Cheers,

Richard



.

Friday, 12 September 2014 07:00:00 (GMT Daylight Time, UTC+01:00)  #    Comments [0]


# Thursday, 11 September 2014

I was working with some custom build definitions on a training course last week and one of the delegates had a failing build.  After a quick visual inspection I couldn’t spot what was wrong and so I wanted a way of easily comparing the build with my working build definition.

I knew we could pull the information using the TFS API and the IBuildDefinition Interface but I came across a flag on the TFS Power Tools (tfpt.exe) builddefinition option that I hadn’t realised was there.

tfpt.exe builddefinition /diff “<Project>\<Build Definition 1>” “<Project>\<Build definition 2>” /collection:<collection url>

This gives us a really quick and simple way of comparing the build definitions and it uses the Visual Studio file comparison to show the differences.

For more information on the command, launch a Developer Command prompt and type:

tfpt builddefinition /diff /collection:<collection url> /?

image

So, for example on my demo setup

  • Server = TFS2013
  • Collection = RippleRockCollection
  • Team Project = BuildDefinitionTest
  • Baseline Build = BuildDefinition1
  • Build for Comparison = BuildDefinition2

image

I used:

tfpt builddefinition /diff “BuildDefinitionTest\BuildDefinition1” “BuildDefinitionTest\BuildDefinition2” /collection:http://TFS2013:8080/tfs/RippleRockCollection

You’ll probably find an error saying:

Could not load file or assembly 'Microsoft.TeamFoundation.Build.Workflow, Version=12.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.

image

You can find Microsoft.TeamFoundation.Build.Workflow.dll in:

C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\PrivateAssemblies

and simply copy the file to:

C:\Program Files (x86)\Microsoft Team Foundation Server 2013 Power Tools

Tfpt.exe should now launch Visual Studio and make the definitions very easy to visually compare side-by-side.

image

Cheers,

Richard



.

Thursday, 11 September 2014 21:57:47 (GMT Daylight Time, UTC+01:00)  #    Comments [0]


# Monday, 23 June 2014

Most Team Foundation Server (TFS) administrators know how to license developers.  MSDN licenses are the most common, meaning that all users already have a Client Access License for Team Foundation Server, are also licensed to install a server and have access to the latest product updates and versions. 

Occasionally users misunderstand that MSDN licenses are “per developer” meaning that only the named user can access software downloads.  On the flip side, that user is then entitled to install Visual Studio on whatever machines they choose (including their home PC) but just remember that most software available for download through MSDN is for development, test and evaluation purposes - not for production.

The most common mistake users make when it comes to developer licensing is when using Team Foundation Server through Team Web Access (TWA).  There are different levels available for TWA which I will discuss later in this post.

However, when it comes to licensing non-development users such as project managers, ScrumMasters, Product Owners and project stakeholders, there is a lot of confusion.

No license (Web Access: Limited)

Having no TFS license still allows you to access some information in TFS and also to contribute to a project.  There are two options:

1.) You can access Team Foundation Server Team Web Access with “Limited” permissions (you may also hear this referred to as Work Item Web Access (WIWA) or Work Item Only View (WIOV)).  If the TFS administrator grants you access then you will be able to submit Bug Work Items or Feature Requests for example, through a web browser.   You can only view Work Items that you have created.

View work items that you have created

2.) You are entitled to view standard reports on TFS if your TFS administrator has granted you permission.  This was a licensing change back in 2012 and applies to TFS 2010 and later.

We have removed the TFS CAL requirement (you still need whatever Sharepoint/Office licensing is appropriate) for viewing reports in TFS.  This addresses a long standing concern that it was not reasonable to require a CAL for the occasional stakeholder who wanted to check a report to see progress or issues.  Add this to the Work Item Only View CAL exemption that we added a couple of years ago and you get a pretty comprehensive solution for the occasional, loosely connected stakeholder

Your team can create custom reports and make them available to you but you will not be able to create your own custom reports.

See TFS Reports for details on the standard reports available with your chosen process template.

Example of Remaining Work report

Also, have a look at the “When a Client Access in Not Required” section of the Visual Studio and MSDN Licensing White Paper for further information.

Any read-only data that comes from the Team Foundation Server SQL data warehouse or is surfaced through SQL Server Analysis Services would be a report, but custom reports could also be written to call into Team Foundation Server APIs and could also join that data with other data sources

Client Access License (Web Access: Standard)

Inexpensive Team Foundation Server Client Access Licenses can be purchased with or without Software Assurance.  If you choose to buy “License Only” (without Software Assurance) just remember that your CAL will be tied to a specific version of Team Foundation Server.  So, when your developers decide to upgrade the server to TFS 201x, technically your CAL for TFS 201x-1 is no longer valid.

A TFS CAL allows you to access all information in TFS.  You can use the client that makes sense for you including the Team Explorer for Microsoft Visual Studio.

Visual Studio Professional includes a CAL for TFS.

Visual Studio Professional or a TFS CAL gives you a Standard license for Team Web Access.  This means that you are not licensed for some features.

Review the article Team Web Access: Change access levels for a full list of features by TWA access level.

Note that the feature list changed between TFS 2012 and TFS 2013.  If you are using TFS 2012 then with a standard CAL, you are not licensed for backlog management, sprint planning and Kanban board functionality.

Visual Studio Premium/Ultimate/Test Professional License (Web Access: Full)

You can view a breakdown of features available in the various versions of Visual Studio here.  Additional features are available through Team Web Access if you are licensed for one of the following as they give you Full access:

  • Visual Studio Test Professional
  • Visual Studio Premium
  • Visual Studio Ultimate

I always think there should be a name for this like SuperCAL or CAL++ because while you cannot buy it separately, it is the thing that trips most people up. 

Most notable for non-development users are the things listed on the right hand side of the following table:

Features available with Team Foundation Server 2013 2013 CAL

Features requiring Test Pro, MSDN Platforms, Premium or Ultimate

Task Boards and Kanban Boards

Backlog Management and Sprint Planning Tools

Request and Manage feedback

Test Case Management

Agile Portfolio Management

Team Rooms

Work Item Chart Authoring

If you have Product Owners or Stakeholders for example, who are licensed with a TFS CAL but want to use Team Web Access to update portfolio information or contribute to Team Rooms, they will need to upgrade to Visual Studio Test Professional as the most inexpensive way of obtaining a Full license for TWA.

Another example is testers who want to use the web-based Test Case Management functionality of TFS Team Web Access.  Even if they do not intend to install Microsoft Test Manager, they will still need to upgrade to Visual Studio Test Professional

Conclusion

Licensing Visual Studio/TFS/MSDN is probably not as complicated as you think but there are many permutations of the way people use the software and the licensing reflects that. 

If you are in any doubt then refer to the Visual Studio and MSDN Licensing White Paper (mmmmmmm, 34 pages of licensing information), contact Microsoft or your Reseller.

Cheers,

Richard



.
Tags:

Monday, 23 June 2014 15:57:58 (GMT Daylight Time, UTC+01:00)  #    Comments [0]