Change Management practices: How to use TFS ensure that we release what was tested and approved

Question

How do teams ensure that the code that was approved in QA is the same code that is released to production?

What automated controls does TFS provide to ensure this?

Also, how do you cross reference compiled code to source code so that you never have to wonder if you need to recompile again?

We come from a Classic ASP shop where source code and released files are one in the same. We do our deployments from VSS. However, we are moving to .NET and are having growing pains and concerns for lack of control over the code.

Answer 1

TFS doesn't provide automated controls for this, as far as I have seen.

What we do is label the source code whenever a build is made. When QA is happy with a build and we are moving to production we branch at the label and build from that branch.

You don't actually need to branch, but just build from the approved label. If you are not using labels you can perform a get on a change set number to get the project at that value and build from that, you just need to know what was the change set number you built from for QA.

You know if you have to build again if there have been checkins since you labeled the branch or if there are newer change sets.

You can also use a continuous integration tool to build a new version on every check in. CruiseControl.Net is one example of this. TFS has one built in but I have not used it.