Question

Using the VS 2008 GDR update, I have created a database project. I have created a SQL Server deployment package. I have created a database unit test.

Using some wizards, the stuff got into my tfsbuild.proj file so near the end of the automated build process a database is created.

I lack a little control of the whole process, I now see. What I would like to do is manually deploy the DB, run 3 custom scripts against the DB, and then manually start the DB unit test. I have other non-DB unit tests that already run. I do not want to use VSMDI or ordered unit test stuff because in out multi-developer environment it gets messy.

Help!

Answer 1

Perhaps I m misreading or missing some details, but it seems to me that the problem is branch management, not automated testing. Most orgs would absolutely love to get to where you are, full automated build and DB unit test.

If it gets messy in a multi-development environment it may indicate developers are checking straight into a branch that runs automated tests. Ideally you should only run BVTs on the important branches and let developers check in into private branches. Private branches are manually tested, then reverse integrated when appropriate (feature complete, stable milestone etc). The automated build and test process picks up the reverse integration check in and drops a new build, running the BVTs and all that. This way you isolated the contiguous integration and BVT process from the churn or constant check in of incomplete features.

友情链接