Rolling back a change set

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.

The First One

So, I have re-named the data structures.  I used the database project template in Visual Studio 2010, and to be honest I wasn’t impressed. As a database management project tool, I found it almost impossible to commit the updated changes back to the database.

But first, let me look at what I did and what I liked and what I didn’t like at each step.  My first step was to use a clean install of the project and get that imported into the database project.  That worked pretty well.  It created one file for each database object (stored procedure, table etc.) which I thought was great.  It created a good structure which was pretty easy to understand (for a non DBA like me).

To me, this structure is very similar to the structure that you see in the MS SQL Studio, which is a good thing in my mind.

Then I did one of the items on my version 2 list for the project, to rename the database tables.  The refactoring was very much in line with the way code gets refactored in VS2010.  It was quick and easy, and every reference was renamed.  Needless to say I did like that.

Now to the parts I didn't like.  I wanted to set one of the tables to save the data within as it was part of the project, not the dynamic data of the system usage. I could not work out how to do this.  I would have thought that a database project would have been able to allocate some default data to the tables, if not mark some tables as having all their data from the project loaded into the implementation of the project.

This leads to my next problem.  I got the source data structure from a database.  I made a relatively simple if somewhat extensive change.  I then wanted to update the database with the changes and it would not update.  Kept on returning a user error or something.  I am going to be honest here.  This to me is the core of a database project.  Writing scripts is one thing.  The ability to use a GUI to manage the code is awesome.  The UX for updating the data structures is not.

As a result, at this time I am not going to use the database project for my changes.  At least until I am able to resolve the 2 issues that I have encountered so far.  So, at this stage I have renamed the database tables, and am about to tackle another of the items on the list.