Tuesday, June 10, 2014

Modifying Other Workspaces as an Admin in TFS 2013

There was a need to modify my build machines TFS 2013 workspace from the default (local) to a server workspace.  Since the workspace was private I could not view it in the UI so I had to turn to the command line.  This will be useful as other users will have issues and as an administrator I need to know how to do this.

To get a list of workspaces you can use the following command.  This will help in finding the workspace you need to alter.  This assumes you have added the path to tf to your PATH environment variable.  It also assumes your DNS to your TFS farm is called tfs

tf workspaces /computer:NameOfComputerWhereWorkspaceResides /owner:* /format:detailed /server:http://tfs:8080/tfs/YourCollectionName

Once you have located the name of the workspace and it's owner you can now alter the workspace.

tf workspace WorkspaceToModify;OwnerOfWorkspace /location:server /collection:http://tfs:8080/tfs/YourCollectionName 

The above command will change it to a server workspace.  Another thing you might want to change for build machine workspaces is the File Time field.  The File Time is set to current which will set all the files to the current time on Get Latest.  The preferred settings for a build machine is Checkin.  That way any files packed for release have a more realistic time of when they were created or last modified.

Friday, June 6, 2014

What is a WIQL variable?

What is a WIQL variable?


In TFS 2013 there are variables you can use in the queries that link to some predetermined Microsoft value.  I always wondered what they were called.  Recently I was reading an excellent post regarding a workaround for the Current query dilemma.

This was the number one hit for it...
WIQL (Work Item Query Language) is the query language for Work Items that Test Management adopts for querying test objects. In Microsoft Test Manager (MTM), WIQL queries are hidden away from users and only the query results are displayed.

It gives a pretty good description.  It is from 2010 so there have probably been many updates to the language and variables available.  Unfortunately @Current still isn't one of them.

Thursday, June 5, 2014

CruiseControl.NET and TFS 2013

CruiseControl.NET and TFS 2013

So in our move to TFS 2013 from SVN we do not initially plan to change our build process over to TFS yet.  Currently we are on CruiseControl.NET 1.8.3.  Upon research this release doesn't officially support TFS 2013.  That was a later enhancement in 1.8.5.  However we are not prepared to upgrade to 1.8.5 (one change at a time).  What I am left with is trying to get 1.8.3 to work with TFS 2013.  It does have a "vsts" source control provider.  Below are my notes on getting this working.

Source Control Path Filters

If you specify a workspace name CCNET will create it but it doesn't appear to be in a format 2013 UI or command lines understand.  What I mean is if you list the workspaces via command line or in the UI you will not see it.  However it is there.  When I checked a file in no build triggered.  I recommend manually creating the workspace on your server and specifying it in the name.  Even with that I get this error when I forced a build (it never triggered):
ThoughtWorks.CruiseControl.Core.CruiseControlException: Warning default.htm - Unable to perform the get operation because the file already exists locally Warning help.htm - Unable to perform the get operation because the file already exists locally Warning D:\Dev\SCM\main\WebSites\SCM\default.htm - Unable to perform the get operation because the file already exists locally Warning D:\Dev\SCM\main\WebSites\SCM\help.htm - Unable to perform the get operation because the file already exists locally at ThoughtWorks.CruiseControl.Core.Sourcecontrol.Vsts.LookForErrorReturns(ProcessResult pr) at ThoughtWorks.CruiseControl.Core.Sourcecontrol.FilteredSourceControl.GetSource(IIntegrationResult result) at ThoughtWorks.CruiseControl.Core.Sourcecontrol.MultiSourceControl.GetSource(IIntegrationResult result) at ThoughtWorks.CruiseControl.Core.IntegrationRunner.Build(IIntegrationResult result) at ThoughtWorks.CruiseControl.Core.IntegrationRunner.Integrate(IntegrationRequest request)
I had to go into the TFS Explorer UI and override the files.  I wonder if it was because I forgot to set the workspace to a server workspace with Checkin times.  After fixing the workspace and editing the file again I was able to force a build with no issue.  However it still is not picking up on changes and triggering automatically.

I believe it has something to do with my path filters or project in the ccnet.config or my workspace mappings in TFS.

In SVN my path filter appended to the URL so if you specified your <turnkURL> as http://svnserver/svn/trunk you could use a path filter of /branchUnderTrunk/**/*.  This would trigger a build for any file under http://svnserver/svn/trunk/branchUnderTrunk.  This doesn't work for TFS.  Below are some examples of what did work for me.  They include wild cards before the path and using the full TFS path.

<inclusionFilters>
   <pathFilter>
      <pattern>/Processes/**/*.*</pattern> <!-- Does not work -->
   </pathFilter>
   <pathFilter>
      <pattern>**/Scripts/General/**/*.*</pattern> <!-- Does work -->
   </pathFilter>
   <pathFilter>
      <pattern>$/TFSProject/TRUNK/WebSites/**/*.*</pattern> <!-- Does work -->
   </pathFilter>

</inclusionFilters>


Source Control Project and Working Directory

This is what I have learned about the <project> and <workingDirectory> elements in the ccnet config for the vsts source control block.  The <project> element doesn't necessarily have to the just the project root ($/TeamProject).  It can be a subdirectory.  This matches up to the Source Control Folder mapping in the TFS workspace UI.  The <workingDirectory> then maps to the Local Folder.

As I changed these settings and did an edit on the workspace I would see the changes.  Keep this in mind as what ever you initially set in the workspace you manually created may not be what it is after Cruisecontrol.NET alters it.

If your workspace in SVN only had certain subfolders locally and not the whole folder structure you can mimic that by cloaking the folders you don't want to sync by editing the TFS workspace.  After doing this and kicking off another build CCNET did not alter the workspace config.

Monday, June 2, 2014

TFS 2013 Administration Tool and SharePoint 2013 Permissions

Team Foundation Server 2013 Administration Tool and SharePoint 2013 Permissions

I was following all of the instructions throughout the internet about the best way to manage users in TFS.  I landed on using AD groups and managing the roles those groups played using the TFS Administration Tool.

This is a matrix describing each role to assign in the tool.
Software
Readers
Contributors
Project Leads
Team Foundation Server
Readers
Contributors
Project Administrators
SharePoint Foundation or SharePoint Server
Visitors
Members
Owners
SQL Server Reporting Services
Browser
Browser
Team Foundation Content Manager

I setup all of our teams and the corresponding AD group and assigned these roles.  Everything worked fine except the SharePoint permissions.  No one was able to view the sites I had created except for me.  I could not figure out why because when I looked in SharePoint they were assigned.  The odd thing was when I did a Check Permissions on the user in SharePoint Site Settings -> Site Permissions the user showed as having no permissions.

When I added the user in SharePoint I then had two users and really started scratching my head (I am not a SharePoint administrator so not that familiar with it besides the out of the box settings).

Luckily I was not the only person having this issue.  Vote this up as it will make our (TFS Admins) lives easier.  It turns out there are multiple authentication methods you can use with SharePoint 2013.  The default happens to be Claims Based Authentication.  Most likely the TFS Administration Tool only works with Windows Authentication.  So for now I will have to use SharePoint to assign user permissions for TFS and not the tool.

Any other SharePoint kinks I need to be aware of?  Let me know.  Otherwise I will post them as I come upon them.

Image courtesy of  Stuart Miles / FreeDigitalPhotos.net

Wednesday, May 28, 2014

Excel Services in SharePoint 2013 Prompt for Data Refresh

While working to get the various dashboards to work for the TFS 2013 Agile template I noticed the all the charts kept asking me Do you want to enable these queries.  After clicking on yes a few times this got old.  Did some digging and there is an easy way to allow them to connect to there data sources and refresh when the page loads.

Here is the message I was talking about:
To remove the warnings you will need to do the following.
  1. Browse to your SharePoint Central Administration page
  2. Under Application Management click on Manage service applications
  3. Click on Excel Services Application
  4. Click on Trusted File Locations
  5. For both your short name address (http://shortname/sites) and FQDN (http://sitename.mysite.com/sites) change the Warm on Refresh setting to No/False and click on OK to save it
Happy Face!  No more click on Yes

Tuesday, May 20, 2014

TFS 2013 Excel Charts in SharePoint 2013 Aren't Showing Areas

I am still in process of setting up Microsoft Team Foundation Server (TFS) as an Application Life-cycle Management (ALM) solution for a company.  All of the companies products are being managed under one Team Project and I am breaking it apart by using teams and areas.

Upon searching there was little documentation out there regarding how to set this up in SharePoint.  The best sites I found was by Martin Hinshelwood and can be found here.  In addition to the instructions listed there is some additional configuration needed for each sub-site so that it only shows the area's affected.  After the various dashboards are present several Web Parts need to have their queries adjusted by adding the area for that team to it.

Web parts that needed adjusting for the Agile template were:

  • Project Work Item (right side)
  • Recent Checkins (right side)
  • Burndown dashboard -> Open Issues (bottom)
  • Bugs dashboard -> Active Bugs (bottom)


Next I went to the Excel Reports on the left to start to modify those for each sub-site.  When I opened one up and went to select the area to match the sub-site it was not listed.  I found this odd since the area I had created was available for the queries of the web parts I changed earlier.

After some tinkering I realized that the areas for reporting off of don't show up until you have created a work item and assigned that area to it.   I created a work item and stepped away for a meeting.  When I got back and reopened the spreadsheet the area was now present.  Not knowing the inner workings of TFS I can only assume this had to be done for the area to be created in SQL Server Analysis Services cube.  If you are setting up the SharePoint sites ahead of time I would recommend you create dummy work items and get the areas populated.  That way you can reconfigure each sub-sites spreadsheets ahead of time.

Happy TFSing!

Image courtesy of  renjith krishnan / FreeDigitalPhotos.net

Tuesday, May 6, 2014

Story Points in Agile for Defects



Story Points for Defects

I have been working with several teams on implementing TFS as they want to follow ALM.  Currently they are doing velocity and burn up charts in a spreadsheet.  I noticed that they were assigning story points to defects.  They were doing so to help with planning as a certain percentage of the teams time is dedicated to fixing defects reported by the customer.  I started thinking about if that was the right way to go about it.

If story points are the measure of value delivered to the business or customer then defects should have a negative impact on the value.   A piece of working software with no defects has a perceived value of non-working software (defects).   Therefore fixing the defects later should be 0 story points since that “value” was already delivered to the customer in a previous release.
 Teams with better quality will have a higher velocity and teams that spend more time fixing bugs will have a lower velocity.  This may portray a more accurate picture when planning work and releases.



Your thoughts?

Image courtesy of ddpavumba / FreeDigitalPhotos.net