June 18, 2010 2:52 AM | Comments [0] | by Ed Blankenship
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.
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.
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.
See for more information: Back Up the Reporting Services Encryption Key
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?) :)
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.
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.
The 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:
As I already mentioned above with testing out build process templates, I have several build definitions in this team project:
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:
What other types of things do you think, dear reader, are important to store in this team project for managing TFS?
Ed Blankenship
Remember Me
a@href@title, b, blockquote@cite, em, i, strike, strong, sub, sup, u