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.
Last week, at the BUILD conference, Microsoft announced the general availability (GA) of Visual Studio Online. That’s great news, but this however impacts your current account and team projects living on the service. The first important thing to note is that the “early adopter” period of Visual Studio Online is nearing its end. On May 7 th, 2014, the early adopter period will stop.
Many of the users started out with VS Online before there was a clear view of how the future of TFservice (as it was called previously) would like like. Because of that, some people may want to take this transition to GA as an opportunity to reconsider their ALM configuration and move to an on-premises TFS server. Therefore, Microsoft enabled a data export window for any customer that has been on the service and wants to “opt out”. You now have the option to export your data from Visual Studio Online in a format that can be imported to Team Foundation Server 2013 Update 2. The data export process is a transfer of a faithful reproduction of your Visual Studio Online data. Read More
In this post, I will demonstrate how you can migrate your TFS on-prem to TFService in the cloud. This process will migrate your sources and your Work Items. When you want to migrate from an on-prem version to the cloud, the only viable option is using the Integration Platform. Because using the Integration Platform can be challenging (if you Bing/Google the integration platform, you’ll see what I mean), I want to guide trough the required steps to perform a migration.
In this post, I want to show you some of the new features and changes in the 2013 version of Team Foundation Build. In my opinion, there are some nice little things that will make your life much easier! Let’s go!
TFVC and Git
With TFS 2013, you now have the possibility to create a Team Project using Git as version control system. This will create a central GIT repository where you can push and get files from/to. Visual Studio 2013 will offer you a great GIT experience. You can find some information about the GIT story on the blog post from Harry Brian. Read More
In this post, I’ll guide you trough the process of installing Windows Server 2012 R2, SQL Server 2014 CTP1, and on top of that the brand new TFS 2013 that was released in preview yesterday at Build. The reason I do this post? Well, I just love using the latest bits and finding out the different compatibility options. So, be aware that this post will mainly consist out of screenshots, many screenshots.
Let’s go. What I did was creating a new Hyper-V machine on my existing Windows 8 host. Give it some memory (4096MB seems to be enough for this basic installation). Boot the machine using the Windows Server 2012 R2 image. Just follow the wizard.
NOTE: you can of course also create a brand new Windows Azure Virtual Machine using the Windows Server 2012 R2 template. Just just ignore the first part of this post.
Windows Server 2012 R2
Active directory domain controller (optional)
Allthough this step is optional, I decided to install a AD DC controller on this machine. I just wanted to know if there were any changes to this process, comparing to 2012. To start, select “Add Roles and Features” and add the role “Active Directory Domain Services”.
And that’s it. Your machine is an AD controller. What you can do now is adding some AD service accounts like SQLService, SQLRS, SQLAS, TFSService,..
SQL Server 2014 CTP1
Next step, the installation of SQL Server 2014 CTP1. But first, a big “do not forget”: You need to have .NET 3.5 enabled. I was hoping that the SQL Server installation wizard would handle this, but you have to install it manually. Otherwise, you will get this great warning:
Team Foundation Server 2013 Preview
And now finally the installation of TFS 2013 Preview. Not a difficult one, as with the previous components, it’s as easy as completing the wizard. Start the installer:
Select the ‘Advanced‘ option, as I want to select my SQL Server, Reporting and Analysis Services
Enter your service account. I did it the “right” way and used an Active Directory account
Use the default settings
Populate the URL’s from your Report Server installation
Test the SQL Server Analysis Services instance
Enter your “Report Reader” account (again, I used an AD account)
I did not configure SharePoint, as it’s only a lab environment
Create a new Team Project Collection
Verify the “Readiness Checks”
There you have it! TFS 2013 Preview has been installed
To verify, open the TFS Administration Console
To test the installation, I’ll just create a new Team Project using the new Visual Studio 2013 Preview, I used GIT as version control system:
And the web access:
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!
In this post, I want to talk a little bit more about how you can build those shiny new SharePoint 2013 Apps using a TFS 2012 build server, but especially: without installing Visual Studio! To start, I will shortly guide you trough the process of setting up a TFS Build Server (with 1 controller and 1 agent).
You might be wondering, why do you setup a separate TFS Build Server? Why don’t you just use the Hosted TFS Build Server? Well, that was also my intake, but it just doesn’t work (yet). The Hosted Build Server does not have the “Office 2013 and SharePoint 2013 Developer Tools” on it, so it’s not able to build SharePoint 2013 apps. So for now, a separate server will do the trick.
TFS 2012 Build Server
Let me start with a quick overview of how to setup a TFS 2012 build server. In my scenario, I’m using a fresh Azure-hosted Windows Server 2012 VM. Fast and easy setup. Download the TFS 2012.1 installer and start the ‘Build Service Configuration Wizard’:
The next few steps are just a ‘next-next-next‘ experience, use the default settings as they are provided. Once you’re ready, you should see that it has one controller and one agent connected to your TFS Server.
CI Build Definition
Now comes the tricky part, how can be build SharePoint 2013 Apps without installing a full-blown Visual Studio 2013? Which components do you need? Well, we’ll start by creating a Windows Azure Auto Provisioned App like I’ve described in another post. Once you have this app, add it to Source Control, and perform a check-in.
Next step is to create a build definition which will perform a continuous integration build of our app. Using Visual Studio, go the the ‘Builds‘ section of Team Explorer, and click ‘Create New Build Definition‘. Give it a name and select ‘Continuous Integration‘ as trigger.
On the ‘Build Defaults‘ section, select the Build Controller we’ve just created, and define where you want the drop output to be stored. I will just use a drop folder in Source Control (which is a new feature in TFS 2012).
On the process section, select the solution file, and leave the other settings by default. That’s it for the build. To try, just queue the build manually, and you should see a nice failing build. That’s completely normal of course, as we didn’t install any build-related things on the build server yet:
Now that we have the build, we need to make the necessary changes on the build server (where the actual Build Agent service is running). Install the following components in the right order:
That’s a tricky one. It will start the web platform installer, and it will give you this error:
That’s correct, we don’t have Visual Studio installed, and that’s exactly what I don’t want! But when you click OK two times, you will a nice overview of all components required:
We can now use the Direct Download links provided to install the required components:
When installing this, you’ll get another nice warning about the ‘Microsoft Web Developer Tools’. Just click ‘Continue‘
There we go, another nice screen telling me that I need the Windows Identity Foundation Runtime.
My build server is a Windows Server 2012 machine, and there you can ‘enable’ the WIF runtime as a feature on that machine. When you enabled this, just retry the setup of the WIF SDK.
- Microsoft Identity Extensions (Dependency) (that’s required for OAuth2.0 usage in the App)
Almost there! If you queue a build now, you will see the following nice error:
Correct, that piece is missing on the build server. To solve this, all you can do is ‘copy‘ the folder ‘C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\WebApplications‘ from your development machine to the Build Server (on the exact same location). That should do the trick! If you now queue your build, you will get:
That’s it, you have your SharePoint 2013 building on clean, fresh Build Server without installing a full-blown Visual Studio 2012. It was quite a challenge, but thanks to Xavier Decoster and some research I managed to get this thing working!
In a next post, I will explain you how to build an APP package with the TFS Build Server. It’s not that simple as just adding “/p:IsPackaging=True” as extra ms build argument unfortunately.
Some extra information: In case you are wondering why I install the Windows Identity Foundation SDK (Dependency)? You can just use the .NET 4.5 Framework, and WIF is already in there. But you need to have the WIF SDK 4.0 to be able to install the WIF extensions. So… You just have to know..
In this post, I just want you to show how extremely easy it is to upgrade an existing TFS 2012 Update 1 machine to the Update 2 CTP that was released earlier this week. There are some awesome new features in this update (without even taking the GIT support in account, which is not yet available for the on-prem version)
Looking at the upgrade process, it’s quite straight forward. First, download the CTP (link) and click on the “tfs_server.exe” file. The first message you will get is some information about the fact that you’re testing a CTP and you may not use it on a production server (which is obvious!).
Next step is to wait until the installation process completes. Note that on my machine (Windows 2008R2), an instant reboot was required!
Starting from there, it’s just a matter of clicking the ‘Next’ button. Nothing fancy! Here you go:
The last step is to validate upgrade process. Everything was looking good, except one thing:
This was related to the following:
TF252039: The following process template cannot be uploaded: 'MSF for Agile Software Development 6.1'. A process template already exists on the server with that name.
TF252039: The following process template cannot be uploaded: 'MSF for CMMI Process Improvement 6.1'. A process template already exists on the server with that name.
TF252039: The following process template cannot be uploaded: 'Microsoft Visual Studio Scrum 2.1'. A process template already exists on the server with that name.
No problem, just saying that the process templates do exist already. So process template changes related to the Update 2 CTP. The last step to complete is re-enable the build controller and agent:
That’s it! Now it’s time to enjoy this new update!
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.