Technique: Using Visual Studio Team Foundation Server To Create A Deployment Package

In one of my projects, we have this requirement that every time we need to deploy the application for QA and User Acceptance testing in a separate server, the developers need to create our individual deployment package containing the codes that changed during the development, either to create new features for the application or to fix some bugs. These packages will then be used by the Build Master who will consolidate them to create the final Visual Studio solution with which to build from.



One of the pains during the creation of these packages is the fact that for every file that changed we need to create the corresponding file to be included in the package. This is not a problem if during the development you only change one or two source files. The process becomes an issue if you happen to change from 10 to say a few hundred files during development of a Change Request, for example. In that case, it's a real nightmare to create this package.

To add insult to the injury, our source control system (Visual Studio Team Foundation Server 2008) does not have a feature (that I know of) where you can just say: "Please select the files affected by Changset 123 and dump them to a temporary folder in my machine". If it were that easy, this requirement of ours will not be a source of contention.

The Technique

After several frustrating episodes of this happened to me, in a moment of pure laziness, I accidentally occurred to me that there might be a simple solution. Here's how my thought process kicked in during this moment of lucidity:

1. Since I know that the copy of the solution has a one-to-one mapping between the Team Foundation Server in the server (our source control) and its location in my local development machine, maybe I can take advantage of that. In this example, we can say my folder is located at "C:\MyProject"

2. Before I checked-in the source files I was working on, I decided to create a Shelveset (where you can temporarily store the code you are working on, undo your changes, and retrieve them later and continue from where you left with your changes intact). This Shelveset will be my source when creating the package.

3. After creating a Shelveset, I checked-in the files. My code is now part of the entire solution and there's no turning back from there.

The question now becomes: How do I create a package for my recently checked-in files?

4. Since the files I checked-in are the same as the files I used during the creation of the Shelveset, I then do an Unshelve operation to retrieve those files.

5. But before the Unshelve operation, I went to my Windows Explorer, look at the folder where my project is mapped to, and renamed the folder from "C:\MyProject" to "C:\MyProjectX"

6. After the rename operation, you basically broke the mapping between the server and its location on the local development machine. But the TFS 2008 does not know nor care about it at this time.

7. The next step is to continue with the Unshelve operation. Since the local folder where the project is mapped to does not exist anymore (because I renamed it), TFS 2008 will recreate this folder (and all subfolders) during the Unshelve operation.

8. Once the Unshelve operation is done, you can verify that the files and folders have been created in the original target folder ("C:\MyProject"). This is now the folder containing the source files you modified and only the source files you modified, coming from the Shelveset.

9. You can now rename this folder from "C:\MyProject" to "C:\MyProject_Package" or to any name.
10. Restore the "C:\MyProjectX" folder to "C:\MyProject".

11. Optionally, you can do a "Get Latest" operation in Visual Studio 2008 to re-synchronize your project with the files in the TFS 2008 server,

You can now send the files in Step 8 to your Build Master for consolidation.

I hope this helps those who are making the same tedious operations like we did before.