I used to invoke the BuildStore.asmx to get the build info from TFS 2008, such as work items, build steps, change set, etc.
But recently, our project moved to TFS 2010. And the BuildStore.asmx is deprecated. TFS 2010 offers a new object model to provide these info.
So, in order to minimize the code change, I want to know the counterparts in TFS2010. Thanks for any hints.
I found some info about the build API in TFS, such as:
http://blogs.msdn.com/b/buckh/archive/2006/09/14/getbuilduri-getbuilddetails.aspx
But they are mainly about TFS2008.
You can make use of direct service-calls. The counterpart you re looking for should reside under "http://TfsName:Port/tfs/TeamCollectionName/Build/v3.0/BuildService.asmx".Another, possibly far more efficient, approach is to write code against TFS-SDK, which should 'survive' from TFS-version to TFS-version. There are numerous resources out there regarding material, this article by S. Raiten seems to be a good jump-start.
I just found some useful material:
http://social.msdn.microsoft.com/Forums/en-AU/tfsgeneral/thread/92766815-c09b-422b-91fc-5e745e3aaa21
Related
I am working on a TFS Implementation where the original Project that was created has a cpace in the name. This is causing issue in our builds since we need to kick off a batch file for the Deploy process and the space in the name creates some issues with the path name of the build folder. With this, I want to create a new project without the space. As you can imagine, I would like to keep the revision history of the Source Code if possible.
I have looked at this StackOverflow
Team Foundation Server - Moving Source with History
But I am a bit confused about what I would need to do. Is there someone out there that can point me to a document that is more friendly to someone who doesn't have a lot of TFS experience.
We've been faced with a similar task and we've used the TFS Integration Platform which might be of use to you.
Here's a couple of good blog posts on how to use it:
TFS Integration Tools - Part 1
TFS Integration Tools - Part 2
I'm new on TFS SDK, and I demand is there a possible way to get a statistic of used langages on a project hosted on TFS 2012 "Programmatically" ?
like on github :
You could probably write your own by accessing a specific solution, (possibly) downloading and 'counting' the number of language resource files.
It is likely that this is similar to what is happening above, it is certainly not a method that I am aware of within TFS.
Is there any way of exporting Test Cases and Shared Steps from one project to another in TFS 2012 using database queries?
I have tried TFS Integration tool, but it did not work as I expected, so I was wondering if there is any way of doing this by connecting to SQL Server and exporting all items directly from and to the databases.
A few days ago I needed an Excel testcase export for a newer version of TFS (TFS 2013). Turns out that there is still no export to Excel function built-in to TFS (in contrast to E-Mail and Printing) and the tools became incompatible over time.
But I found this Revival-Tool that seems to work:
https://github.com/jorupp/ExportTestCases
Just wanted to point that out even if it may not be directly related to this topic with TFS2012.
You shouldn't work directly in the database, because it is not supported by Microsoft and you could harm it a lot.
I used the TFS Integration Platform tools a lot for migrating TFS2010 projects, but never used it for TFS2012. My experience with that were good and it shouldn't be a problem to migrate all Test Cases and Shared Steps into another TeamProject. If you have the same Work Item Type Definitions in both projects, you don't need to create field mappings.
Another option would be to use Excel as "Export" and "Import" cache, but you might loose some information, because not everything could be shown in Excel, e.g. Steps of a TestCase, the history, Work Item Links.
If you are skilled in programming using TFS API, you could write your own small migrator, but this could be a lot of effort.
All in all the TFS Integration Platform should be the easiest and best way, so what have been your expectations that have not been fulfilled?
You can use an alternative methods.
First export all Test cases using "Test case extractor."
Them import them in new project using "Test case import tool."
Adding to the point mentioned above, for exporting the test cases you might find the below link more useful:
http://tfstestcaseexporttoexcel.codeplex.com/
I have given it a try and found it very useful and easy to use.
I am relatively new to MSBuild and am looking out for good resources to learn more about MSBuild and CI with TFS. Specifically I am looking out for the following specific tasks
Take latest from TFS whenever a checkin happens
Build the solution
Run the code analysis
Run Unit test cases
On success deploy the project to the drop location
Label the build
I am not looking for any reference to any books. Online resources will be good. I did google for this, but was not able to get and end-to-end tasks for this.
Any pointers in this direction will be appreciated.
Edit:
Also some good resources to custom MSBuild task will be helpful.
This is where I first started.
Edit
I don't mean to be flippant but MSDN really is a good starting place for MSBuild and most things .NET related.
In fact, everything that you describe is part of the standard TFS Build process. At least if you use MSTest for unit testing. Integration with other unit testing frameworks is also possible.
A good starting point would be MSDN, as it is quite exhaustive:
http://msdn.microsoft.com/en-us/library/ms252495.aspx
TFS2008 is very pleasant to work with in regard to Team Builds. The builds can be set up through Visual Studio itself. It was a different and a lot uglier story in TFS2005 :)
You can find a lot resources on the web if you hit any obstacles during the setup. A lot of people are using it and I never had any troubles finding blog/forum posts discussing even the most obscure issues.
Our team would like to move from the Visual SourceSafe (VSS) to the Team Foundation Server (TFS). I know that the TFS is much more than just a version control system, but for the first time I would like to use it this way.
Currently our projects are organized within the single solution that consists of the shared part (common library) and many customer projects.
Is there some kind of migration guide that would describe such a challenge? Or TFS enforces its own usage scenarios (versioning of projects, releases, etc.)?
TFS certainly has much more potential than just as a source repository, but it's quite understandable why you would want to migrate source control first.
The migration utility of choice is generally VSSConverter.exe which allows you to map VSS paths to Team Project source control paths and is pretty well documented in this walkthrough here.
There's another tool (TFS Migration and Synchronization Toolkit) available over on CodePlex, but when I compared the two, I determined that VSSConverter has been more widely used and I think is generally accepted as being the tool of choice for VSS migrations.
It seems there are a few more answers on this thread here also.
Now, the question I think you are really asking is more about guidance on creating Team Projects and structuring?
This is a little harder to answer without knowing more about your specific circumstance. Patterns and Practices published a book on CodePlex called the TFS Guide which might help - it describes amongst many things, a suggested Team Project source control structure. It might help in giving you some guidance around how to migrate and/or remap your solution structure.
Regards to versioning and branching, check out this site here on branching guidance - it's not a bad overview of some common branching/release management techniques using TFS.
If you get through all that reading, you'll really be on top of most of the essential TFS groundwork!
(Feel free to downvote me but...) If you're after better source control then TFS is IMHO overkill. I recommend you look into Subversion. VisualSVN is a superb ($49) plug-in to Visual Studio that works seamlessly alongside arguably the best SVN client TortoiseSVN. In addition they provide a free, easy to set up, Windows package of the Subversion server-side stuff called VisualSVN Server.
To learn all about the Subversion way of working there's the great Red Bean book.
(Not affiliated with VisualSVN, just a Subversion fanboy)
TFS and VSS are radically different beasts.
That said, the major problems with moving from VSS to TFS is generally in the developer's mind.
Check out the following blogs:
TFS from a VSS User's perspective:
http://blogs.msdn.com/robcaron/archive/2006/10/29/901115.aspx
And of course, the original
http://sstjean.blogspot.com/2006/10/document-from-vss-to-tfs-introduction.html
When we switched from Sourcesafe to TFS2005 the biggest hurdle were Sourcesafe's shared files, the "Get latest on checkout" approach and the branch/merge "support" in Sourcesafe. Everybody feared branching and merging in Sourcesafe and it took some time convincing all colleagues that it is not that bad with TFS.
We decided to not migrate files from Sourcesafe. We used TFS2005 for a new project and kept the old stuff in Sourcesafe. We didn't want to keep the project and folder structure which had grown over the years and was rather unorganized.
The old stuff is history now and we do all development work with TFS2008.