we have a very tricky situation which am sure can be avoided if dealt with properly.
There were 5 different branches of a specific application in our TFS 2010. All the branches were merged into 1 branch and since the merging was done by a system administrator who wasn't part of the development team, we ended up cleaning the code (adding the missed changes from 3 separate places where ever they were conflicts) This amounted to almost 2 weeks of extra effort to get the code branch stabilised and tested before proceeding further.
What should be the best practice to be followed to avoid such frustrations in future as we have multiple code branches for different development projects running on same applications.
See the Visual Studio ALM Rangers Team Foundation Server 2010 Branching Guide.
Related
We have a situation where at a point in our project's life, we needed to split off work item tracking and source control into 2 separate TFS projects, with the work items being in a VS Team Services project, and the source on-prem in TFS 2013.
The reason at the time being, we needed to grant access for our stakeholders to the product backlog, without them being on the corporate network where TFS is hosted. At the time there was concerns about security of the source code, hence the whole project was not lifted and shifted, just the backlog.
Now we're realizing some of the security concerns were not warranted, and we are missing out on the integration of ALM provided by a single project having both responsibilities, and would like to merge our source control out into the cloud-based VSTS project.
The problem is, the migration tools are overwriting the Work Items in VSTS. Is there some way we could merge, preserving that data, or any alternative to merge these two things together somehow?
I think you're looking at the Team Foundation Server Integration Tools here if you want to migrate source code history. Bear in mind that it's not going to be perfect (data time stamps will not be the same etc.).
If you can get away with it then just stick the latest code in VSTS and consider the on-prem server your archive should you need to go back. That doesn't tend to be too popular so you'll be wrestling with the integration tools. It's not the most friendly thing to use but mostly it will get the job done.
When you configure your session, you will want to choose Team Foundation Server\VersionControl.xml for your configuration. Then select a One-way-migration between your on-prem and VSTS.
You'll need to install VS 2012 or at least the Team Explorer.
Edit Coincidentally I had to do this myself so I blogged about the process here
we have 2 dev teams, one team work on TFS2005 and the other team work on TFS2010.
it's the SAME project but one team is continue to work on .net framework1.1 project version and the other team work on the .net framework4.0 project version.
WE HAVE ONLY SOURCE CONTROL (NO WORKING ITEMS AND ETC...)
after we do the first import from TFS2005 to TFS2010 to TPC X, can we import after one week just the changes of the passed week?
can we do import (TFS2005 to TFS2010) to the same TPC X (already existing one) ?
can check in can be done automatic to 2 TFS servers ?
I'd avoid splitting your code base accross 2 servers if possible. Once you've moved the code in to TFS 2010 I'd use branching to distinguish between the .net 1.1 version of the code and the .net 4 version.
Once you have the code in branches you can merge the code on a regular basis to keep the versions in step.
You need to think about what branching stratgy works best for your situation, read the guidance on codeplax to help you decide. Your branching strategy will depend largly on whether the .net 1.1 version of your code is being actively developed or if it's just in maintenance / bug fix mode.
If you're using VS 2003 to do the .net 1.1 development you can use the MSSCCI provider to give you basic TFS integration.
From your description it sounds like you already have two versions of this project in two separate TFS Servers. I agree with James that it's best not to split codebase across two version control systems, but sometimes we just end up in this type of situation.
How are you importing from TFS2005 to TFS2010?
This is an important question. TFS2010 does not have a way to import a single Team Project from one server to another. You can Import an entire TPC (Team Project Collection). I know of only two methods:
A) Seriously look at TIP (TFS Integration Platform). It's not perfect, but it is designed to do what you are looking for.
B) You can do a snapshot migration. Basically this means getting latest from VS2005, check in to VS2010 (wherever you want), then leave all prior history in VS2005.
If TIP doesn't work for you or is deemed too risky or missing critical info then find out if TFS2010 can import TFS2005 databases to migrate your TFS2005 Team Project Collection. If yes then make a copy of the TFS2005 Version Control databases, then import the entire Team Project Collection into TFS2010, then delete the other TFS2005 projects from this collection that aren't needed. You can call this your TFS2005 Archive Team Project Collection and keep the full fidelity version history on-hand if needed. I did a migration from TFS2008 to TFS2010 a couple times. It's non-trivial but doable.
Migration approaches:
Plan A: Migrate everything to TFS2010 and retire TFS2005 as soon as you can. You can archive 2005 or perhaps move it to a virtual machine if you feel it's essential to have available... but you really want to cut your admin work in half plus get 5 years worth of improvements by moving everything to TFS2010.
Plan B: Set up a system that allows you to integrate between the two servers until you can finally retire TFS2005. Stay in this situation only as long as absolutely necessary and upgrade whatever you need to unblock moving everything to TFS2010.
Q&A:
After we do the first import from TFS2005 to TFS2010 to TPC X, can we import after one week just the changes of the passed week?
A: It should be doable, but fidelity of import depends on how you are importing.
If you are doing a "snapshot migration" by checking in the latest version of VS2005 code into VS2010 then you can check out the first snapshot, repeat a new snapshot over the code, then merge the changes. The BIG drawback to snapshot migration process is that you lose all metadata in TFS2005 including change history, labels, checkin comments...
If you use TFS Integration Platform hopefully most content and metadata will transfer. The neat thing here is once you define the synchronization rules and run it once you can simply re-run the same migration with minor changes. Watch for how labels and changeset metadata gets transferred.
Can we do import (TFS2005 to TFS2010) to the same TPC X (already existing one) ?
TFS Integration
A: That shouldn't be a problem. TFS Integration Platform or checking in a "snapshot migration" can be targeted to any folder path. I assume there is no formal branch relationship established between the two codebases currently. Therefore I'd strongly recommend checking in the imported files into a separate folder, convert it to a branch (if not already done by import process), then establish whatever branching relationship makes sense to the existing TFS2010 project branch. If there is no shared code between these two projects then I'd keep their branches separated.
Can check in can be done automatic to 2 TFS servers?
A: That's the promise of TIP (the TFS Integration Platform). I personally had a rocky time trying to get it to migrate full source history from one TFS2010 Server to another, but big part of that problem was network issues traveling across 6,000+ miles and 3 firewalls.
Start by reading this blog and it's comments for a well balanced discussion of TIP and current limitations: TFS Integration Platform Updated (Mar ‘11)
Good Luck!
We have 50+ projects divided into 2 solution trees managed by TFS (Version: Visual Studio 2008 / TFS RTM (9.0.21022.8)).
30+ projects are Visual Studio 2008 projects and others are Visual Studio 2010
New projects use some older assemblies via references to binaries.
During developing new projects we have to make changes into older assemblies so we have to keep 2 MSVS instances opened simultaneously.
Is there a way to share compilable sources with TFS between two different studios solution trees? Or shall we upgrade 2008 solution tree to 2010? Does TFS 2008 support shared projects (or may be it have to be upgraded too)?
Thank you in advance!
Andrew:
First off, we violate a couple of "best practices" to accomplish this, but pragmatism is where best practice meets the real world.
What we do is this:
All binaries are checked in to TFS within a LocalBin folder that consolidates all of our binaries.
All shared assemblies are located within a folder called LocalBin/SharedBin
The SharedBin folder is branched to a top-level SharedBin folder within the consuming team project(s).
On a successful main build, the LocalBin/Sharedbin is merged to the projects' SharedBin folders.
It winds up being something like this:
$/ProjectA/Main/Localbin/SharedBin is branched to $/ProjectB/Main/SharedBin and $/ProjectB/Dev/Sharedbin (as well as the equivalent folders in $/ProjectC, $/ProjectD et cetera).
We only do this sharing when we have a successful MAIN build, and the build is responsible for merging not only to the other MAIN branch projects, but also to the DEV branch projects, so they are up to date.
We've toyed around with the idea of coping the binaries to a shared network location after successful build, and having a convention to reference those binaries in that network share, but this process is working well for us today, and we're loathe to make changes to it at this point (more important things happening for now).
This is one of those things that's hard to fully describe in a posting, so if you have further questions, I'd be happy to try to answer them.
BTW, our solution was built and is running under TFS2008 with thousands of project files, and likely millions of lines of code. It does increase the build time due to the merge and increases the amount of space used in your repository, but both have been manageable thus far.
We are a mostly MS shop at work doing .NET LOB development. We also use MS Dynamics for our CRM app... all the devs are currently using VS/SQL Server 2008. We also use VSS, but everyone hates it at work and that is quickly on its way out.
We are begining our initiative for TDD implementation across the team (~dozen ppl). I've gotten TeamCity setup and have my first automated builds running succesfully using the 2008 sln builder and also using SVN that a co-worker had setup who is doing the source control analysis. When demoing to managament, I think they started to buy into my snake oil and threw out the suggestions of looking into TFS.
This threw a wrench in what I had planned for our TDD architecture; In a good way though, because I had always assumed that TFS was just too expensive and not worth it for our team (and i've seen the same in other shops i've worked at / know of). I do feel like MS is years behind in the TDD/CI area and that the third party products were probably much better and more mature... I still need to do a lot of research, but I figured I'd come here to see if anyone has actually used both systems.
I realize the TFS encompasses a lot more then just a build server... but I didn't want to make this too broad of a question at least on purpose. What are the practical pros/cons of using TFS/TFB instead of TeamCity - e.g. which benefits would we lose/gain? Has anyone here actually used both systems (TFS for TDD/CI and TeamCity/SVN) and can speak from practical standpoint?
I've done some searching on this topic, and one post I found here on SO mentioned that the cons of TFB was it only supported MSBuild. I was planning on using FinalBuilder with TeamCity; and it appears it also supports TFS as well...
Thanks for any advice
EDIT: Has anyone used TFS as their Build/CI server and can tell of success/failure stories?
We are a small development shop, and decided that Team Foundation Server carries too much overhead for us. We used to write custom MSBuild scripts to run from the command line, but after we discovered TeamCity, we moved our entire build process over to it.
We've found TeamCity to be easy to use and configure, and JetBrains provides excellent support and documentation. They are also on a much faster release and update cycle than Microsoft.
Their support for SVN source control is excellent, and we like the fact that they support both MSTest and NUnit for unit testing.
We also liked the fact that the TeamCity Professional edition was free, so we could evaluate it to see if it worked for us. We haven't hit the number of project configurations (20) that would require us to upgrade to the Enterprise edition.
This question has a lot of good answers about TeamCity. It does not compare to TFS but it might shed some light on TeamCity for you.
I have used both, and I have had success with both, but TeamCity was so much easier. TeamCity was a breeze to set up and configure. TFS was not. TeamCity is rock solid, it's easy to maintain and it just plain works. The developers at JetBrains have done a great job responding to the community. They get a release out every 6 to 8 months that adds real value. TFS is on a 2 year or more cycle.
TeamCity gives you more choice in how you build and what source control you use. It's not all in one, but that's sometimes a good thing. It's got a good set of extension points as well. We have also been really happy with the agent model it has.
I've gone through 3 absolutely painles upgrades in TeamCity. The one TFS upgrade we did took our build and source control down for 3 days. I'm the admin for TeamCity on our project and it takes up a couple of hours a month. TFS took a couple of days a week.
TeamCity + SVN + VisualSVN has been the smoothest environment I have ever worked in. TFS was generally smooth on the day to day, but only if someone was there keeping it running.
Hope that helps
The benefits of TFS are one integrated environment that is supported by Microsoft. I personally do not like TFS for source control and have had a number of issues with it. It is clunky, however it had the benefit of having VS integration (which is also available in VisualSVN, but is not as robust).
Personally, I think you would be much better off using SVN/TeamCity. It is just easier to work with and behaves more as you would expect. As with most open source software, both are constantly evolving and will always have the latest and greatest feature before Microsoft. The integration between the 2 is really good and I have found no fatal flaws in the system. I constantly push to go this route in my current company (we use TFS), as I believe it is a much better workflow. As an added benefit, it is significantly cheaper than going the TFS route.
I have also used FinalBuilder with TFS - my question there is what are you really buying with FinalBuilder that you can't do with NANT/MSBuild? The answer at my shop is unfortunately very little IMO.
First off, see this post:
SVN vs. Team Foundation Server
As to your question about which environment better fosters TDD and such, my two cents is that the build management system matters much less than what's in the build file itself. Your Ant or MSBuild file should have the targets that do your testing. With MSBuild or Ant, you don't have to use MS's test suite. You can still use nUnit or whatever else you want. That means it doesn't matter if TFS is calling your MSBuild file, or if CruiseControl is, or if TeamCity is. The smarts are all in the build file and the tools you integrate with it.
My personal choice is not to get locked down into TFS's way of doing things, since you have a lot more freedom for a lot less cost with the wealth open-source testing tools that are out there. TFS is about to receive a major upgrade, as well. If you are going to go with TFS, my advice is to at least wait until 2010 is released. Concentrate on making your MSBuild files as good as they can be right now.
That being said, I must admit that TFS has one of the nicest build systems out there (2005 was terrible, 2008 was nice). Being able to easily customize notifications and the release process all inside .NET code was pretty cool -- you had a lot more central control over build and release policy than we did with CruiseControl.NET.
So I've used TFS and SVN/CCNet. I can't speak much to TeamCity. But IMO a build management system should be fairly agnostic to what is being built and how it's being built. For us, the extra control in the release management process that TFS brought us just wasn't enough of a bonus for us to justify the greatly increased administrative effort of a fully integrated TFS solution. Nor was it enough to justify the extra per-license cost of TFS, which can be significant.
The old TFS Build was XAML based and very cumbersome and and not nice to work with. That said, the new TFS 2015 build system is leaps and bounds better, and is script based with lots of web hooks and 3rd party integrations; very similar to Team City. Also, TFS now supports Git, so you are no longer confined to using Team Foundation Version Control (TFVC). Also, with TFS you can use your own on-prem installation, or can take advantage of a hosted solution through visualstudio.com. TFS is great because it's one completely integrated environment (work items, planning, builds, tests, deployments), whereas Team City is just a build solution. When this question was originally asked in 2010 I would've recommended Team City hands down. Now though, the 2 are very competitive. I would say that it would maybe boil down to if you want an all-in-one solution, then go with TFS, but if you are looking for purely just a build system, then Team City.
Comparing TeamCity to Visual Studio Team Services (the latest cloud-based offering from Microsoft):
Both work great for implementing a continuous integration process
TeamCity is more mature and everything just works.
Visual Studio Team Services by contrast is constantly evolving to catch up with TeamCity and some things just don't work well (e.g. try triggering builds based on paths that have changes from Git - the documentation is weak and the feature itself just doesn't work (as of August 2016))
Visual Studio Team Services makes it easy to have only cloud-based agents running your build (the downside however is that each has to do a clean pull of your repository for each build which may add a minute or more to the build). Both can also support local build agents which do not need to wipe the working directory for each fresh build.
But in either case I would highly recommend you also look at CakeBuild which moves most of the configuration information about how to do a build out of the CI system and into C# code that is in your Git repository along with all your other source code. With CakeBuild you can run the same build locally as you will run in the CI system and if you need to go back a month to build a specific version you have the source code and the build script to do it.
With CakeBuild in place you are now free to easily switch between TeamCity and Visual Studio Team Services.
The only downside to CakeBuild is that all your build steps are bundled into a single task in the CI system which makes reporting slightly less nice and may involve some extra work to get the test results out into a format that the CI reporting system can use.
MS is years behind in the TDD/CI area
Being one who has TDD'd for 4 years now you are correct. MS is still not even promoting it nor do they offer tools that work well with the TDD flow.
Don't get stuck dealing with Visual Studio for any kind of automation, source control, or agile workflow period (stop using TFS please!!). That stuff even though they say is "new" is monolithic and always comes with weird issues and bloat. It is always painful.
I've used Team City and it's simply amazing, things work, it's designed for usability, and it's simply designed well and compatible with most all test tools, etc. Fine use Visual Studio for code, nothing else. Look for external and open source tools to help build a better CI. The "you can do everything right in VS" sell is not selling, and it's not working. People nowdays are used to and always combining different tools from the outside to get things done. Relying on all MS toolsets is just not the way to go IMO for .NET. MS likes to sell "hey you can just do everything right here". But you end up with nothing but pain when you go that route and drink their koolade (TFS, MS Fakes, etc.).
If you plan on doing TDD, you definitely don't want to be using all MS tools. You'll either be pushed down "their way" of doing things which is often proprietary and/or bloated when you try to TDD with their tools or be totally restrictive. For TDD you need to be able to have some flexibility and choices when you decide to layer in different test frameworks, assertion libraries, etc.
Add Octopus on top of Team City, and it's stellar...you will simply fall in love with it as developer or for anyone doing DevOps.
Stop trying to rely on Microsofts continued failure at agile tool offerings
Start looking outside the box and try new things is what I keep repeating to the .NET world, me being a .NET developer in the past and who has tried new things outside the MS world.
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.