This project is read-only.
Project Description
Set of development tools for small developers to automate some parts of release management. There are a number of tools I am looking to develop to encourage easier management of a release by coupling these tools with TFS and CodePlex. It is also a desire to interface with other build systems such as TFSBuild and CC.NET. The goal is to allow us to manage multiple development branches, provide QA/Sandbox environments for each one of these, involve stake holders (including developers, qa, business analysts, end users, support providers), and contribute to a knowledge base in a unified way to communicate via TFS and/or CodePlex. It is the desire to reach them via a help desk application, an on screen work item editor for QA, a simple admin tool for pushing a build through various stages and notifying users of actions they need to take and accepting responses. Basically, if you are developing software as a lone engineer, this is to help with the part that we do not seem to have a good tool for.

This is very exploratory at this point, but seems worth investigating. I am going to do most of my dogfooding with a DotNetNuke module to assist in the build/QA/release process as well as the application itself.

Nice addition. The CodePlex client by Brad Wilson has some great libraries that will prove very useful when developing this application.


I've been on several software projects over the year that require a number of different steps to be considered released. Often times we find ourselves scrambling at the last minute to build the package, or go through some painful copy/paste process that is usually developer dependent. Often times I find that if I want to develop a module for something like say DNN, I have to find some simple way to test bugs. As lame as it sounds I find it painful to have to look at something, take a screen shot, save the jpg, annotate as I want, then enter that information into the issue tracker. Not only that but if I have an end user issue, it usually is email. Sometimes an issue is fixed that the customer doesn't necessarily receive notification that it has been fixed.

UPDATE: So I've gone ahead and finally created a blog dedicated to this and other .NET musings. You can find it here

I see a few major components
  • On Screen Capture and Work Item Editor -- Create a user control that would host a Windows control (or possibly some sort of fanciness with Javascript/CSS) that would allow text markup/outlining of something on the page. A text box would also be provided to enter extra information. Based on the page name and perhaps some query parameters be able to classify which component the problem is happening in so we have to collect as little information from the user involved as possible. Regardless of being a QA actor or an end user.
  • Help Desk Application / Work Item Queue Management - an intermediary web application that allows a support provider (helpdesk, etc) to analyze items entered and see if they can recreate and how to direct the item from there. Such as do we need to have a release manager / development manager / developer analyze the item and figure out how to resolve. At this point we would associate the item and let the end user know when it was being addressed and when it can be developed, and when it is released.
  • QA / Sandboxing environment setup - Probably a misnomer to call it this since I only plan to create a "sandboxing" environment for web based applications. I quote sandboxing because my initial designs don't call for creating truly isolated environment. Instead I plan to create workflows that will allow sandboxes to be easily created even incorporating customer data. This is a very lofty goal. But if used in conjunction with the on screen capture tool, QA environments could be easily manageable.
    • Put an emphasis on versioning, so we always know what version people are working with.
  • Automatic release detection - if all workitems are closed and approved by a certain level of approvers (perhaps hardcoded, but maybe some kind soul wants to join in) then a release is automatically created. My dream is to see the system detect the final changes (subscribe to TFS events?), compile up the files for that release, zip them up, upload them to codeplex, generate release notes with the changes, notify direct stakeholders of the release, etc. Lofty goal..
  • Change Log Publishing - Use XML templates, or publish to a blog, wiki, or something new changes. Makes it easier than adding another RSS feed to a users already growing list.
  • Knowledge base - If helpdesk solves an issue with an end user that doesn't require code changes (or perhaps a hotfix) then move the item into a knowledge management tool, that could further decide how to handle it. I would like to create a basic KB tool, but certainly opportunity here to expand it further.
  • Helper Workflow Activities - Create some activities that can be used by others to customize the build process as they would like. Given we are going to use workflow, we should be able to handle a great deal of situations without modification, making it an ideal solution for people that want an out of the box solution as well as making it appealing to those that want to use it as a base for their own release process.
  • Manage the lifecycle of releases over the entire life of the software. This could include documentation, code repository location, knowledge base information, item tracking, test cases, etc. Most would be contained within TFS this would just provide a nice view into it.
  • Compliment applications/technologies like CC.NET, TeamBuild, MSBuild, TFS, CodePlex, and I'm sure a number of other items.
  • Plugin with other item tracking systems such as bugzilla or gemini, and additional code repositories.
  • Probably more, just depends where it goes and people take interest. I think there are some neat possiblities with using workflows for release and defect management.
This idea my end up being horrible, but I seem to have an itch for it and want to see if I can create something powerful for TFS and helping smaller development houses and single developers. I plan to dogfood the application on itss

Development Strategy

Last edited Jun 24, 2008 at 1:38 AM by cege7480, version 9