Yesterday, May 12th, Visual Studio Online exposed a collection of service hooks which sends information to other services on interesting events that happen inside Visual Studio Online – things like builds completing, work items being updated, or code being pushed. Visual Studio Online supports direct integration with over a dozen services, and one of this services is Trello.
Yesterday, I gave a session at the Visual Studio Usergroup (Visug) in Belgium. I talked about how you can leverage the power of Git with TFS 2013 and Visual Studio.
As promised, you can find my slides at Slideshare:
Thanks to the people who joined my session! I hope you enjoyed it!
In this post, I will describe how you can easily ‘move‘ an existing Git Repository (like GitHub, BitBucket,..) to Team Foundation Service or Team Foundation Server 2013. As you might know, TFS Service and 2013 offer Git support as DVCS solution. You can find some additional information about the Git story on the great blog post by Brian Harry!
So, you have an existing Git Repository, and you want to ‘move’ it to TFS? Well, compared to a migration from one server using TFSVC (a topic I blogged about recently) to another server (like TFService), moving a Git repo is a piece of cake! In fact, you have two options
I got a question from a friend of mine (Pieter Turcq) today, who asked me if it’s possible to use one single Project Site (in SharePoint) for both TFS and Project Server? Well, actually you can. In this post, I will show you what the requirements are and how you can easily achieve this. But first let me start with a brief ‘overview’ of how it looks like out of the box.
One of the nice things about Team Foundation Server is that it creates a SharePoint “Project Site or Portal” when you create a new Team Project. This is a place where you can add project documents, view some dashboards and whatever SharePoint magic you want to use. On the other hand, you have Project Server. In some cases, you can have a nice integration between both systems using the Team Foundation Server Extensions for Project Server. This way, you can manage the data flow between TFS and Project Server (but this is not the scope of this blog post). The thing is, if you create a new Project in Project Server, it also creates a Project Site. The total picture will look like this:
Note that this is a situation where the Project Portals from TFS are hosted on another SharePoint environment as the Project Sites of Project Server. (If they are hosted on the same environment, it will of course use a different Site Collection, but you will have less work to get to the end solution. I’ll explain this a bit later). Now, how can we get one Project Site for both systems? We have 2 options: A quick-and-dirty solution, or a decent solution.
The quick-and-dirty solution
The first solution is really simple. What you do is pointing the Project Site from your TFS Team Project to the URL of your Project site of Project Server. You can do this using Visual Studio using Team Explorer. If you go to “Settings -> Portal Settings“. There you can set an option “Use a website“.
It will now redirect to your Project Server’s Project Site. That’s all. Nothing more, nothing less. It will have no interactivity with TFS or what-so-ever, you will not see the Project Site documents in your Visual Studio, you will not have any dashboards on your Project site,.. So this is not an option. Let’s move on.
The better solution
A better solution is to make it possible to let the Project Server’s Project Site behave like it would have been a “standard” TFS Project Portal.
If your are in the same situation like the one I’ve illustrated, you must install and configure the Team Foundation Server extensions for SharePoint Products on the remote portal. If not, you can skip this step, and no actions related to this need to be executed! This is a step that has to be executed for ALL SharePoint application servers. It contains the necessary Web Parts and some dashboards. You have some excellent guides for this, but it really is a straight forward process. Just make sure that you have the right permissions, and especially that the TFSService account that needs to a Farm Administrator.
- How to: Install Remote SharePoint Products for Team Foundation Server
- Configure Team Foundation Server Extensions for SharePoint Products
Great, now our SharePoint instance who’s hosting the Project Server’s Project sites is able to do “TFS related” things. Next, assigning this SharePoint instance to TFS. Open the administration console and click on “SharePoint Web Applications -> Add“
Note: It is import to know that when creating a new Team Project in TFS, we will NOT allow the wizard to create a Project Portal. Because if you don’t watch out, it will create one on your PWA instance directly. This is not the behavior that we want. We want Project Server to create Project site, and link our TFS Team Project to that site manually. So be careful!
Alright, so now that the SharePoint instance of Project Server is known by TFS, we can configure our Team Project to use an existing Project Site from Project Server. Open Visual Studio, go to Team Explorer and select “Settings -> Portal Settings”. Enter the correct settings:
In this example, I use the TailspinToys Project Site from Project Server, to be used as TFS Project Portal from TFS. Be sure to select the check box “Reports and dashboards refer to data for this team project“. Click Ok. If you now go back to Team Explorer and select the “Documents” node, you will see the content of the documents library from you Project Server’s Project site.
Mission accomplished.. or not? Well, it’s great to have the documents library available from your Project Site. But wouldn’t it be cool if you could also use this Project Site to add your TFS Dashboards, and some TFS Related Web Parts? Well, actually you can! If you open your project’s Project Site (in Project Server), and go to “Site Settings -> Site Features“. And activate the dashboard you need. In my case, it’s a TFS Team Project based on the Agile Process Template, so I selected “Agile Dashboard“. If you click activate, you will see some new items in the menu on the left side. That’s exactly what we need. This way, we can also change whatever we want, and we can even add the TFS specific Web Parts like a Work Item Query list.
That’s pretty cool! So there you have it, one single Project Site/Project portal for both TFS and Project Server. Have fun!
Note, when Project Server was not on the same SharePoint instance as TFS, and you followed the previous steps using the TFS Administration Console, and you don’t see the dashboards listed in the features list, be sure that it’s enabled in the Web Application of your PWA! You can check this using the “Central Administration -> Application Management -> Web Applications -> Web Application -> Manage Features“. It should be enabled by default, but you never know! Next to that, if you don’t see any web parts related to TFS, look at the Site Collection Features, and be sure that “Visual Studio Team Foundation Server Web Part Collection” is activated. That’s all!
Last week, I ran into a Coded UI issue at a customer. The problem occurred when I tried to execute my Coded UI tests on a remote test-agent machine (using the 2010 version) The execution of the test was just fine, the (WinForms) application started and waited for initialization (because the application takes quite some time to start). But just on the moment when the first Coded UI test wants to start, the application closed. Quite strange..
The exception I got in the test run result was the following:
Error calling Initialization method for test class CodedUITests.UsabilityCodedUITools: System.Runtime.InteropServices.COMException: Error HRESULT E_FAIL has been returned from a call to a COM component.
W, 12876, 135, 2013/01/14, 14:51:24.272, 79392686980330, QTAgent32.exe, Playback - [WARNING] Internal warning: Playback engine is already initialized and SkipStepThreadEvent has been created. Cannot change the name of event after its is created.
I had no I idea what the problem was, but after some Bing’ing, I found that it was related to the QTAgent Process not being killed successfully after a test run.
Unfortunately, the remedy for this error message Error calling Initialization method for test class xxx: System.Runtime.InteropServices.COMException: Error HRESULT E_FAIL has been returned from a call to a COM component. calls for killing the QTagent Process.
The issue from my side was about the application that has been killed while my tests were running. I didn’t foresee a catch for that, resulting in a QTAgent Process that was not quite behaving like it should have.
To avoid situations like this, you can make use of the ‘Playback.PlaybackError‘ event. This event is raised when an exception occurs during playback.
Just a quick share 🙂
In a previous post, I talked about the Kanban 1.0 process template made by the ALM Rangers. It gives you some basic information, and it also describes how to install the process template and how to create a new Team Project based on this process template. In this post, I will talk a little bit more in detail about how this process template works. Let’s see how it looks like under the hood.
Work Item Types
Let’s start with the work item types you have when using the Kanban process template. The process template provides the following Work Item Types:
- Card: This is the unit of work that is tracked through your software development process. A Card represents value demand or failure demand on your team. You can specify a type of Card. By default the following Card types are provided, although you can customize the card types by changing the Kanban Card Types global list:
- Work Task: This represents demand on your team for work that has value for your customer (value demand).
- Team Task: This represents demand on your team for work that has intangible value. Typically these includes work such as setting test environments, re-factoring some code etc.
- Problem: This represents demand on your team to rectify a problem (failure demand).
- Process Step: This Work Item Type is used to define information about the steps in your process. In particular this is where the WIP limits are defined for each step of your process.
- Blocker: Used to represent a problem that is blocking the progress of a Card. The Card work item has a tab where blockers can be listed.
- Bug: Used to track bugs.
- Shared Step: Used to define a reusable set of test steps.
- Test Case: Defines a test case.
One thing which is really important when using Kanban is the easiness of changing your process. Your process will change over time! One of the requirements of the Kanban Process Template is that it has to be possible to easily change the steps of your process. Let’s take a look at the following image:
In general, you have 3 big states (in blue). A planned (backlog), In Progress and Complete (closed) state. The planned and complete states are the start and end states, and they have no queue associated with them. When you create a new ‘card’ work item, the starting state will always be the backlog. When the card moves to ‘In Progress’, you will have the option to select in which working state it’s in. And those states are customizable.
When you create a new Team Project based on the Kanban Process template, you have 4 ‘working states’. Analyze, Implement, Test and Review. Those states are defined by the ‘Process Step‘ work item. So by default, there are 4 process step work items. To manage the order of the steps in the flow (from left to right), you can use the ‘order‘ field from the work item type. The lower the number, the more left on the flow. By default, analyze is 10, implement is 20, test is 30,… On each process step work item, it’s also possible to provide the Work In Progress (WIP) limit. This number will be used for visualization on the Kanban Board. You can also provide some exit criteria (also known as -the definition of done-). For example:
Global List Synchronizer
When you add a process step to your Team Project, it has to become available to your cards. Meaning that it has to be possible to select the correct state on the card work item. The list of possible states that can be used on a card are stored in a global list on TFS. To synchronize this list whenever you change or add a process step, there is a background process called the Global List Synchronizer, who will synchronize the list of process steps used in the Card Work Item Type with the current list of Process Steps. As you add, change or remove Process Step work items, the list of valid process steps in the Card work items changes accordingly. It modifies the Card work item type definition so that each Team Project uses its own Global List to provide the list of process steps. In fact, you get something like this:
The Global List Synchronizer is something that has to be installed. Installation is really simple, just download the bits from CodePlex. Open the downloaded item, and unzip the file ‘Global List Updater Source Code.zip‘. Open the correct (TFS 2010 or TFS 2012) GlobalListUpdater solution (with either Visual Studio 2010 or 2012). Change the build configuration to ‘Release’ and build the application. In the output folder, you should now see the following files:
Next step is to install it on your Team Foundation Server. The installation process is quite simple.
- Log in to the Application Tier server.
- For Team Foundation Sever 2010: Copy the compiled assemblies (including the .config file) to <System Drive>:\Program Files\Microsoft Team Foundation Server 2010\Application Tier\Web Services\bin\Plugins.
- For Team Foundation Server 2012: Copy the compiled assemblies (including the .config file) to <System Drive>:\Program Files\Microsoft Team Foundation Server 11.0\Application Tier\Web Services\bin\Plugins.
- If you have multiple Application Tiers, repeat step 1-3 for each of them.
After you copied the files to the plugin folder, TFS will detect this and will restart the application tier. This way, the plugin will be hooked to TFS and will be able to interact with TFS events (like work item changes). You can see this in the event log:
To test if the plugin is doing its work, open a process step work item (using Visual Studio, or the Web Access) and change the title of the item. Save the work item. Now create a new ‘card’ work item, save it in the ‘backlog state’, change it to ‘In Progress’ and see if you can select the modified process step. In my case, I changed the process step ‘ Implement’ to ‘Implement(test)’. You also can look at the event log on the TFS server, and you will see all output of the plugin listed there:
Ok great, so now you have an overview of how the process template is constructed, which work item types you have and how the Global List Synchronizer works. In a next post, I will show you a little bit more about how you can use the process template, how you can use the work item queries and how you can use reporting to view all information about your Kanban process.
Thanks for reading!
In this blogpost, I want to talk a little bit about how Team Foundation Server can help you to support your Kanban Process. We will use the Practical Kanban Guidance from the ALM Rangers, where I am also a part of the team. I will talk about the the process template requirements and how to get started.
First of all, really short: what is Kanban? Well, Kanban is a method to visualize the development work flow and the work in progress. Kanban has 5 principles:
- Visualize the workflow
- Limit WIP
- Manage the flow of work
- Make process policies explicit
- Improve collaboratively
Using these aspects, you can highlight any bottlenecks in the development process. You have a visual overview of the things which are happening in your team, so you can guide it. Perhaps change the process, change the WIP limits, ..
As you know, the way TFS supports your development process is defined by a process template. This is a collection of files that together define various process elements of a team project. There are a number of requirements that need to be satisfied to allow teams to get the most out of a Kanban-enabled process template for Team Foundation Server.
1. The process template should make it easy to modify the states in the process flow: Kanban is about continuous improvement. During the life of a project a team may wish to modify their flow, adding or removing states. Therefore the process template should make it easy to add and remove states in the process flow.
2. The process template should allow Work In Progress limits to be represented and reported on: One of the few fundamental concepts in Kanban is to limit the amount of work in progress (WIP). This means that the process template should allow us to specify a WIP limit for each state in the lifecycle of a card.
3. The process template should allow each state in the process flow to have an In Progress and Done sub-state: The process template should allow for In Progress and Done sub-states and report on WIP limits across the two sub-states.
4. The process template should support arbitrary state transitions: Kanban is not a software development method and does not dictate anything about how a team should implement its process. Therefore a card should be allowed to be moved into any Kanban state from any other Kanban state.
5. The process template should support hosted Team Foundation Server instances: To give teams maximum flexibility, a Kanban-enabled process template should not require project collection administration rights to make changes such as the states in the process flow and WIP limits.
6. The process template should include a Cumulative Flow Diagram Report and a Kanban Board: It has to be easy to see when bottlenecks are occurring, in which state the cards are, what’s the cycle time,..
Microsoft Kanban 1.0
Based on those requirements, the ALM Rangers came up with a brand new process template called: Microsoft Kanban 1.0. This is a flexible process template allowing you to easily adapt your Kanban process on Team Foundation Server. You can download the process template here, including all documentation and guidance you need.
In a next post, I will explain how the process template actually works and how you can use it. But first, let’s take a look how you can install this process template. Once you have downloaded the bits (both Team Foundation Server 2010 and 2012 are supported), you need to upload it to Team Foundation Server, so that you can create a new Team Project based on that template.
1. Open Visual Studio (we will use 2012, but it’s quite similar on 2010), go to ‘Team Explorer’, click ‘Settings – Process Template Manager’, there you click ‘Upload’ and locate the folder with the process template. I will use ‘Microsoft Kanban 1.0 – dev11’, because I’m using TFS 2012.
2. After the upload is complete, you should now see ‘Microsoft Kanban 1.0’ in the list of process templates.
3. Now create a new Team Project using this process template. In Team Explorer, go to ‘Projects and My Teams -> New Team Project‘. Complete the wizard and select the Kanban process template:
4. That’s it. You have a Team Project based on the Microsoft Kanban 1.0 process template. If you open your Team Explorer, go to Work Items and you can start creating cards (based on the Card Work Item Type) and model your process (based on the Process Step Work Item Type).
More in-depth information about how to use the process template will follow in a next post. I will also talk about ‘the Global List Synchronizer’, who will be responsible for the synchronization of process steps.
If you have any valuable feedback, just leave a message or start a discussion on the codePlex forum.
Today, I was was trying to create a build definition to run an Ant build from a Java project in Eclipse. First of all, I installed the brand new Team Explorer Everywhere for TFS 2012 RC (which looks really good!). Next step was to install the Build Extensions (to support Ant and Maven 2/3 builds). The installation went perfect, no problems at all.
Next step is to install Winant to support Ant builds on a Windows operating system. I also installed the Java SDK (including the JRE, otherwise you cannot run Eclipse). When all this was finished, I created my build definition like I normally do (I made a blog post about this a while ago).
Only.. there was a quite strange behavior when I queued my build. It only took 2 seconds. According to the build output, the Java project was successfully built, but the build was red. When I looked at the logs, I found this error:
Error: Unable to access jarfile C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\BuildExtensions\apache-ant\lib\ant-launcher.jar
This is strange, but on the other hand correct because ant-launcher.jar doesn’t exist on that location.
Solution: When you install the Java SDK and Winant, it creates 2 environment variables. The thing is that it creates ‘User’ variables, and not ‘System’ variables. So what you have to do is create 2 system variables and append the bin paths to the ‘path’ system variable. In my case:
“ANT_HOME = C:\Program Files (x86)\WinAnt”
“JAVA_HOME = C:\Program Files\Java\jdk1.7.0_04”
“Path = …………………;JAVA_HOME%bin;ANT_HOME%bin;”
Next, restart you build service (to catch the new added system variables) and queue your build. As you can see: Issue solved 🙂
Today, I updated my TFS 11 machine to the recently released TFS 2012 RC version. More information about this release can be found on the the great blogpost by Brian Harry. Updating an existing TFS 11 setup is really easy, just uninstall the Application Tier and perform the installation of TFS 2012. When the setup is ready, you can follow the -upgrade- path to convert your existing databases and settings to TFS 2012. This went perfectly without any issues. Great job Microsoft!
So far so good. Although this is not the goal of this post. I want to share you something I was struggling with. When I looked at the homepage of my web access, I had this 2 red dialogs:
This behavior is really strange, because I did install the full version, nothing special, just a standard upgrade. I also found out that I didn’t have a ‘Backlog’ in the activities menu on the right, allthough I had this on the TFS 11 version (and on the TFS preview version). When I browsed to this page manually by going to http://tfsserver:8080/tfs/DefaultCollection/TeamProject/Team/_backlogs, I had this same permission error:
After some research, I figured out that you now have the possibility to define ‘Web Access Permissions‘ in this version of TFS. By default (meaning after the upgrade), this is set to ‘Limited‘ = no advanced features like the backlog etc. To activate this, just go to the Admin Control Panel, select ‘web access‘ and select ‘Full‘. Then click on ‘Set as default web access‘. You can also play with those settings by adding users to specific permissions. As you want…
That’s it, issue solved!
When I was at a customer last week, I had a situation that SharePoint Foundation 2010 was installed as a local instance on the TFS application tier. The TFS extensions for SharePoint were already installed using the TFS installation. Now the SharePoint Foundation 2010 instance had to be changed to a farm installation. So the SharePoint Content and Configuration databases had to be located on a data tier (SQL Server 2008 R2). After the re-install of SharePoint Foundation 2010 in a farm mode, the TFS extensions for SharePoint had to be installed again.
When I went to the Team Foundation Administration Console, the ‘Extensions for SharePoint Products’ were still there (as it was previously connected to our local SharePoint Foundation 2010 instance). The problem was that the TFS extensions were not available anymore on our new SharePoint instance. When I click on the ‘Extensions for SharePoint products’, I got the error:
“TF249063: The following Web service is not available: http://abc:17012/_vti_bin/TeamFoundationIntegrationService.asmx. This Web service is used for the Team Foundation Server Extensions for SharePoint Products”
That’s correct, that TFS integration service asmx was not available anymore. The first thing I did was an un-install from the extensions (using the TFS installation media). Then I did a re-install of the extensions, but without any result. I hoped those steps could solve my problem, but they didn’t.. Time for the next step.
stsadm to the rescue
To resolve the issue, you have to install the TFS extensions manually to the SharePoint solutions store, and then deploy them. To do this, you need the stsadm tool from SharePoint. That’s the command-line administration tool from SharePoint. You have to add 3 .wsp files to your SharePoint farm.
- Go to the directory: C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\bin\
- Open a command window (Shift + right-click -> Open Command Window here)
- Be sure that you run the command window with a user who has the right credentials (SharePoint Farm Administrator and have rights to the Central Admin Content Database on SQL server)
- Run the following commands:
- stsadm -o addsolution -filename “C:\Program Files\Microsoft Team Foundation Server 2010\Tools\Templates\Microsoft.TeamFoundation.SharePoint.wsp”
- stsadm -o addsolution -filename “C:\Program Files\Microsoft Team Foundation Server 2010\Tools\Templates\ TswaWebPartCollection.wsp”
- stsadm -o addsolution -filename “C:\Program Files\Microsoft Team Foundation Server 2010\Tools\Templates\Microsoft.TeamFoundation.SharePoint.Dashboards.wsp”
- Open your SharePoint Central Administration (http://server:17012 or something equal)
- Go to system settings and click ‘Manage farm solutions’
- You should see the 3 TFS wsp files
- Click on the first one, and click ‘Deploy Solution’
- Deploy the solution by clicking ‘Ok’
- When you deployed the 3 solutions, you should see
- All you have to do now is grant access for your TFS instance to SharePoint using the TFS Administration console.
That did the trick for me. Thanks for reading!