One of the most common issues I am finding with teams moving from Team Foundation Version Control to TFS-Git is that they are including files in their repositories that they shouldn’t. The most common offenders are .suo user settings files, Nuget packages and Azure publish settings. Luckily, the solution is straightforward.
1. Ensure you have no pending changes.
2. Close the solution
5. Open the .gitignore file from GitHub that is specific to Visual Studio projects and copy the contents to the clip board. https://raw.githubusercontent.com/github/gitignore/master/VisualStudio.gitignore
Figure: the .gitignore includes a list of all of the files that you want to avoid committing to your repository
10. If you have included files in your repository that you wish to exclude from the repository but not delete from your local working directory refer to
on my page for
Configure Your Build
1. Open the Build Pane
Figure: From Team Explorer choose Builds
2. Create a new build definition
Figure: Click on the New Build Definition link
3. Enter build definition name “AdamS.MembershipSample.CI”
(CI for Continuous Integration)
4. On the Trigger tab choose ‘Continuous Integration’
Figure: Remove any items that do not apply to your project (sometimes items from other solutions will appear in this list – remove them)
6. On the Process tab, ensure that the solution is being built
7. Save the Build
Configure Build Notifications
1. Run the Visual Studio Build Notification application.
From C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\BuildNotificationApp.exe
2. Select the build
Figure: Select the Build that you just created and click OK
Start a Build
Figure: When the build is complete, you will get a green or red icon indicating the status.
I got asked for a 60 second intro to using TFS-Git.
1. Go to your personal TFS (e.g. adamstephensen.visualstudio.com)
2. Create a new Team Project
Figure: Click on New under Recent projects & teams
3. Clone your Repository locally
4. Add your MVC project to the Repo
The default Agile TFS template ships with three states: New, Active and Closed.
A common question that I am asked is how to add an extra stage to the TFS taskboard.
While this is not trivial in TFS 2012, it’s really not that hard once you know how, and is being made easier in newer versions of TFS.
Figure: We will demonstrate adding a ‘Testing’ column.
Step 1: Ensure that you are an administrator of the Team Project you are updating
Step 2: Download the Team Foundation Server 2012 Power Tools
– In Visual Studio select Tools, and then Extensions and Updates
Figure: Select Online from the left menu, enter Team Foundation 2012 in the search field, click the Download button on Microsoft Visual Studio Team Foundation Server 2012 Power Tools
Step 3: Export the Task Work Item Type
To add a new column to the task board, we need to add that status to the work item type definition.
Figure: From the Tools menu select, Process Editor, then Work Item Types and then Open WIT from Server
Figure: Expand the correct Team Project and select the Task work item type.
Step 4: Add the Testing state to the Task WIT
Figure: Select the Workflow tab. Open the toolbox and drag a State component onto the design surface. Right click on the new State, select Properties and set the Name property to Testing
Figure: Select the Transition Link component from the toolbox. Now click on the Active state and drag your mouse to the Testing state.
Figure: A transition will have been added from Active to Testing.
Figure: Right click on the Transition and choose Open Details. Go to the Reasons tab and Edit the reason value. Suggested test: ‘Ready for Testing’. You can click on the chevrons to expand the transition to be able to more clearly see the assigned properties.
Additional actions and Fields can also be specified but that is beyond the scope of this post.
Figure: Repeat the process above to add transitions from Testing to Complete (with a reason of ‘Testing Complete’) and from Testing back to Active (with a reason of ‘Failed Testing’).
Figure: Save the template to a known location on your hard drive so that it can be imported in the next step. E.g. c:\Temp\TeamProjectName_Task.wit
Step 5: Import the saved WIT
Figure: From the Tools menu select Process Editor, then Work Item Types and then Import WIT.
Figure: Browse to the location of the saved file, select the Team Project you wish to import the WIT into and click OK.
Figure: When you edit a task, the Testing status is now available. It is not yet however added to the board.
Step 6: Export the Process Template Config
This is the part that I always forget to do. After you have edited the Work Item Type, you still need to update the process template to include the State on the Task Board.
Figure: Open a command prompt, change to the Visual Studio IDE Folder and execute the following command
witadmin exportcommonprocessconfig /collection:CollectionURL /p:ProjectName /f:”DirectoryPath\CommonConfiguration.xml”
for our instance the command required was
witadmin exportcommonprocessconfig /collection:http://ourserver:8080/tfs/CollectionName /p:ProjectSparrow /f:”c:\Temp\CommonConfiguration.xml”
Step 7: Edit the Process Template Config
Figure: Edit the exported file. Find the section for TaskWorkItems and add the line highlighted above.
<State type=”InProgress” value=”Testing” />
Save the file.
Step 8: Import the Process Template Config
Figure: Execute the following command
witadmin importcommonprocessconfig /collection:CollectionURL /p:ProjectName /f:”DirectoryPath\CommonConfiguration.xml”
for our instance the command required was
witadmin importcommonprocessconfig /collection:http://ourserver:8080/tfs/CollectionName /p:ProjectSparrow /f:”c:\Temp\CommonConfiguration.xml”
Figure: View your task board and you will have your new column!
I love continuous deployment to Windows Azure from Team Foundation Service! http://www.windowsazure.com/en-us/develop/net/common-tasks/publishing-with-tfs/
Often though we need the flexibility of building and working directly with the WebDeploy package.
I had a conversation today with a lead developer who was working with a team who couldn’t get the hang of not checking in bad code. To resolve the issue, he implemented Gated Checkins. He asked me to check out some the code and I was happy to, right up until I had to do a few checkins. The following are my subsequent thoughts on the matter.
Gated checkins are used to stop developers from checking in bad code and breaking the build.
This does not contribute to high functioning teams, and instead masks, or even creates dysfunction.
To illustrate lets look at a couple of examples.
In the retro the team decides to turn gated checkins on because Jonny and Sue keep breaking the build.
The build doesn’t get broken any more, because Jonny and Sue now have to fix their code before they check it in.
This doesn’t mean that Jonny and Sue are writing better code, it just means that they are not checking in code that breaks the build.
Gated checkins will not improve their skill level, change their attitude or improve the quality of their code.
The development ninjas on the team are proud of their code, and check in several times per day.
Because the gated checkin takes 10 minutes their workflow is impacted.
They resent Jonny and Sue for having to work this way.
Gated Checkins mask the dysfunction on the team, and introduce impediments to the high performers.
Example – Gated Checkins mask dysfunction
In the retro the team discusses the fact that the build is often broken.
After a round table discussion about becoming better programmers and building better quality software, the team decides to the following guidelines:
1. The team will all run build notifications so that everyone knows when, and by whom the build is broken.
2. If someone needs help with solving a problem, they are going to feel good about asking for help early, and learning something new in the answer.
3. If someone is asked for help, they will gladly share their knowledge to ensure that the quality of the project is maintained ,and the team help each other to become better developers.
4. Before checking in, the devs will compile and run all tests. **
5. If someone checks in and does break the build, they will call out to all members of the team that the build is broken so that no-one gets latest. They will fix the build IMMEDIATELY, and then call out again when it is fixed.
(Some teams have a rule that if you break the build three times you have to shout coffee / lunch).
6. The team agrees that you don’t go home if the build isn’t green.
If it comes to the end of the day and you are not sure your code will not break the build – do not checkin. Create a shelveset and resolve the issue properly the next day.
If you have checked in, the build is broken, and you cannot fix it before going home, you must email all devs on the team, and the product owner with an explanation.
7. The status of the build is reviewed in every daily scrum. Edit: Gerard correctly pointed out that this is bad Scrum.
Example – The whole team should be constantly aware and invested in the status of the build, the quality of the software and in encouraging each other to better developers.
** I actually don’t follow this rule when working on small teams of awesome devs, who write code against tests and checkin frequently.
Instead I encourage the process to be
– checkin 4-5 times a day
– write lots of tests
– if the tests that you are working against pass- checkin and let the build server do a full compile and run all the tests
– if you have broken the build, call it out, fix it immediately and then call it out again.
This is the most productive way for small teams of awesome developers to produce great code… and it’s fun !