Delete Team System Builds

Some features of Team System can only be reached at the command line.
Unfortunately deleting a build is one of these.

You will need to use the "Visual Studio 2008 Command Prompt" (or "Visual Studio 2005 Command Prompt"). This has the the 'Path' variable correctly set to find 'TfsBuild'.

C:\Program Files\Microsoft Visual Studio 8>tfsbuild /?
Microsoft (R) TfsBuild Version 8.0.0.0for Microsoft (R) Visual Studio 2005 Team System(C) Copyright 2006 Microsoft Corporation. All rights reserved.

TfsBuild help [command]

command The name of the command you want help on

List of commands:
start Starts a new build on the build machine
delete Deletes completed build(s)
stop Stops the build that is in progress
help Prints this help message


Usually you will need to stop a build before deleting it.

c:\tfsbuild stop http://tfsserver:8080/ "Tfs Project Name" samplebuild_20080529.4

Then you can delete it:

c:\tfsbuild delete http://tfsserver:8080/ "Tfs Project Name" samplebuild_20080529.4

So How Long Is Team Server Taking to Backup?

The backups of our Team Server came into question the other day.
It was suspected that the backups were running for a very long time and during this long run they were degrading the performance of other aspects of Team System.

One of the cool things about SQL Server is nearly everything about SQL Server's operation that can be stored in a database, is stored in a database. The database 'msdb' contains information about backups in the tables 'backupset' and 'backupfile'. So the following query will show how long it took to run backups (adjust the date):


SELECT
s.backup_start_date,
s.backup_finish_date,
s.database_name,
f.logical_name,
f.file_type
FROM backupset s, backupfile f
WHERE s.backup_set_id = f.backup_set_id
AND s.backup_start_date > '2008-05-20 10:01:16.000';

All that Team System

Say anything about Microsoft Team System and chances are you will be wrong because your information and/or understanding of Team System is incomplete.

Version Control is all new. Most of what you know based on SourceSafe no longer applies. Much of the rationale for using alternative version control systems is no longer true. Keep your eye on changesets.

Risk Tracking is a new feature introduced with Team System. You may have developed or purchased a separate system for this. You will have to reconsider because this Risk Tracking system is natively integrated with Version Control.

Bug Tracking is also a new feature of the Team System. Again you may already have one in place. And again you will have to reconsider because the Bug Tracking system is natively integrated with Risk Tracking and Version Control. Notice a pattern? It goes deeper recall those changesets that Version Control uses? The resolution for a bug can include links to the changeset that fixed the bug.

Work Item tracking follows the same story, integrates with Bug Tracking, integrates with Risk Tracking, integrates with Version Control. Again huge benefits from linking the changesets that satisfy the Work Item.

Unit Testing, Regression Testing, Performance Testing, Environment Testing; again integration with all the rest of Team System.

Likewise the Build features of Team System.

Now it is possible that you have cobbled together a collection of systems that do all of these things. Perhaps you have even integrated them and managed to get them to work together. If this is the case then there are two very probable outcomes. One is that significant effort goes into keeping the patch work collection of systems working. If not then certain quirks, annoyances and bugs is just tolerated and worked around on a daily basis.

But that isn't the end of the story. There are more features to Team System, plus we just got an update with version 2008 that contains even more. One could despair of ever catching up on this one offering from Microsoft.

But there is hope. When Visual Studio came out there was a similar flood of features, and with each new version of Visual Studio more tools were added. We never caught up with Visual Studio. In a way we never had to catch up. We just started using it. The more we learned the more efficient we worked. It was always a balancing act between getting it done and spending time learning how to do it easier. We survived the Visual Studio feature flood. We will survive the Team System feature flood. And what a great problem to have!

permalink

12 Basic Software Development Practices

The gap between programming or writing code and developing software is growing.
This paradox is driven by the proliferation of easy to use tools, libraries, frameworks and OSes designed to ease the burden of software development.

Regardless of why, my experience has been that the typical software development shop is not executing on basic fundamental software development practices. A trend of late that I find even more alarming is quite often many of the programmers and managers are not even aware of or do not insist upon implementing them. It reached the point that I have enumerated 12:

12 Basic Software Development Practices

1. Source Control
2. Issue Tracking
3. Bug Tracking
4. Work Item Tracking
5. Environments
6. Integration Builds
7. Automated Builds
8. Unit Testing
9. Regression Testing
10. QA
11. Versioned Releases
12. Setups

So for a while my thinking was I can just enquire about these 12 before taking a new contract or engagement and all will be well. It is not surprising that I was always told "oh yeah we have all of that.." And it is also not surprising that expectations did not match reality. So I formulated follow on questions to determine the depth of practice.

Questions to determine depth of practice

1. Source Control

Where is the code kept?
Central location?
Individual machines?
Which version is authoritative?

2. Issue Tracking(Issues are a catch all term for everything that does not fall into the bug or work item buckets. They include but are not limited to 3rd party software issues, network issues, development machine issues.)

Is there a Central reporting tool / repository for issues?
Is there an established work flow?

3. Bug Tracking

Is there a Central reporting tool / repository for bugs?
Is there a bug workflow which includes states for:
Initial
Approved
Denied – Feature, works as designed
Denied – Not reproducible
Fixed
Verified
Reopened
Closed

4. Work Item Tracking

Is there a Central reporting tool / repository for new feature and enhancements?
Is there a work flow which includes states for:
Initial
Coded
Test
Failed
Accepted

5. Environments

Do separate environments exist for each of?
Development
Integration
Quality Assurance
User Acceptance Testing
Production

Is developer access to environments higher that Development limited?
Is developer access to environments higher than Integration denied?
Does QA or Change Management own the process of moving releases from one environment to the next?

6. Integration Builds

Does the code build from source control?
Does it build on a machine that is not a development machine?

7. Automated Builds (hourly/daily)

Is the code being built a regular basis?
Is this build done by an automated process?

8. Unit Testing

Do developers check in unit tests with their code?

9. Regression Testing

When code is built for release are all unit tests run?
Bug, Feature and QA tests?

10. QA

Is QA done by someone other than developers?
Does QA write automated or unit tests to demonstrate bugs?
Does QA write automated or unit tests to test common test cases for a feature?
Does QA write automated or unit tests for security and other required practices?

11. Versioned Releases

Is there a version number definition?
Are the products tied to the version number with each release?
Is the version number incremented with each release, both internal and external?
Does QA report bugs and test features according to version number?

12. Setups

Does each application have an install program?
If it does not have an install program are there instructions documented for manually installing the application?
After the install does the program run or is more intervention required?

Footnote. Microsoft Team System can provide them all.

permalink