Managing TFS Artifacts Using TFS



Many years ago, I really thought the fact that SQL used itself to manage itself was pretty cool (i.e. master database.)  For the past several years, I have been doing something pretty similar and someone just reminded me that it was an interesting concept.  I use TFS to manage the artifacts needed to manage TFS.

TFS Team Project

The first thing I end up doing is creating a team project usually named “TFS” to hold all of the artifacts.  I personally only give the TFS Administrator permissions to the project.  As you’ll see, there may be security sensitive content that may be stored in this team project.  From time to time, other developers may help out with some of the custom tools that can be created to extend TFS.  I’ll create special team project security groups and permissions to those security groups for those particular scenarios.

Reporting Service Encryption Key Backup

After I have setup the TFS team project, the first thing I check-in is the backup of the encryption key from SQL Reporting Services.  It’s extremely important for disaster recovery scenarios that you have a backup of the key since the encrypted contents of SQL Reporting Services won’t be recovered if you don’t have the key.  By checking the key file into version control, you can always make sure you’ll have it backed up with the regular SQL backup process of the databases.

image

See for more information:  Back Up the Reporting Services Encryption Key

Process Templates

image Managing changes to process templates is one of the main reasons I had originally had the idea of creating a team project to manage TFS artifacts.  I think version control is the perfect place to manage changes to all parts of your process templates, especially work item type definition files.  I even create two branches of the process template folders:  one for the production environment and one for the test environment.  This allows you to manage changes just as you would your software releases.  Work item type definition changes definitely require some testing especially since there are risks in causing issues with certain changes.  (Has anyone ever messed up the warehouse?) :)

Build Process Templates

I keep all of the “golden” copies of build process templates in this team project.  I usually perform my actual development work for build process templates in this team project as well and will usually have some test build definitions to try them out.  You could also easily use your staging or test TFS server for this effort too.

Custom Build Assemblies for Build Controllers

One of the awesome new features for TFS 2010 is the ability to store custom build assemblies (like workflow activities, build tasks, build process parameter custom editors, etc.) in a version control folder that the build controller can notify build agents to monitor to deploy those assemblies to each of the build servers in your build lab.

If you want to deploy a new version of those assemblies, just check in the new version and all of the controllers & agents will use them for the next build they perform.  Pretty awesome if you ask me.  I create a folder in the TFS team project just for this purpose.

SNAGHTML6d53cc

Source Code

imageThe TFS team project is usually the main location where I will store source code for all of the different extensibility points for TFS and Visual Studio.  This list of custom tools isn’t exhaustive by any means but should give you some ideas of the type of source code that could be contained in this team project:

  • Custom Check-In Policies
  • Custom Build Workflow Activities and Build Tasks
  • Custom Work Item Controls
  • Web Service Event Handlers for TFS Events
  • Custom Testing Data Collectors (Diagnostic Data Adapters)
  • Migration Utilities and Adapters
  • Custom Code Analysis Rules
  • Global Code Analysis Spelling Dictionary
  • Custom IntelliTrace Event Collectors
  • Other Visual Studio or TFS Tools

Builds

As I already mentioned above with testing out build process templates, I have several build definitions in this team project:

  • Testing Team Build 2010
  • Deploying Process Template Changes to Test & Production TFS Servers (I plan on having more information about this process in a future blog post.)
  • Custom Tool Builds

Other

Don’t stop with this list.  If it’s something that helps to manage TFS, feel free to store it in this team project.  Here are a few other examples of the types of artifacts I use this team project for:

  • SQL Queries to manage the data tier
  • Custom SQL Reporting Services Reports

 

What other types of things do you think, dear reader, are important to store in this team project for managing TFS?

Ed Blankenship



Name
E-mail
(will show your gravatar icon)
Home page

Comment (Some html is allowed: a@href@title, b, blockquote@cite, em, i, strike, strong, sub, sup, u) where the @ means "attribute." For example, you can use <a href="" title=""> or <blockquote cite="Scott">.  

[Captcha]Enter the code shown (prevents robots):

Live Comment Preview