Recently, I was working on a TSF Team Project project that had 2 branches. I was continuously merging my trunk with each of these branches, as all three projects moved forward. Recently I was given the go ahead to merge one of the branches into the trunk. After checking and rechecking, I did this.
After about an hr after I had merged one of the projects into the trunk, I was, as usually happens, asked if I could make a change ASAP and release (in a way that would have the least impact on testing resources). This meant that I needed release a version of the code that mirrored the current Production environment as a base with the necessary changes. My first thought was that I would grab the change set, update the code, build on my local and release that. However there was a gotcha, there was a requirement to have the build that was deployed done on the build server (with the TFS auditing of changes etc).
Anyways, I grabbed the required change set, made the changes, tested it locally, then checked it in, and released the result from the build server. After checking that the release worked, I handed it over to the testers. I then re-merged the code with the other 2 branches (luckily I hadn't deleted the one that I had been told to move into the trunk) so that they had the latest change. Now, in TFS, merges use code on the server to merge, not code on your local (at least as far as I can tell). As I was reviewing the changes and resolving the conflicts, I was seeing code from the trunk that included the branch I had merge into it. Needless to say I got to wondering what had been built and then released to UAT. I grabbed a tool to review the binaries that were in the release, and it was based on the project that I had merged into the trunk! There was code there that I knew wouldn't be tested, and as such could not be released as this would increase the risk the change was raising (testing only the features of any change can mean that other impacts of the change are not identified until a full regression test is done).
So, I was left with a dilemma, how can I revert to a change set and release that change set, using the build server and all appropriate auditing in TFS, without having to manually remove all untested code and create a greater risk? Then, after some googling, I came across a post by Mike Fourie, which details one of the new features in the August 2011 release of the Team Foundation Server Power Tools. TFS 2010 has the ability, though the command line, to perform a roll back. This extension brings that functionality into Visual Studio 2010 with a usable UI. Let me just say that this saved my weekend from being an entire coding wreck. I was able to roll back to the required version, then re-build and re-release only what was desired. I wont re-write how it works, Mike does that well enough, but here are some links:
Mike’s Post: Using Rollback in the Team Foundation Server Power Tools
Team Foundation Server Power Tools August 2011
I hope this helps others out there who are wanting to (or having to) roll back code to a previous version on the server.
