Reputation: 2319
How do you or have tried to protect your source code repositories from commits that introduce bugs or break builds? It seems that forced regression testing upon commit can go a long way towards preventing bugs from creeping into projects worked on by multiple developers. However, most common code versioning tools don't offer any features in this area.
Here is one method I have experimented with. I created subversion pre-commit hooks to generate a copy of the project with pending commit's changes merged in, then it ran syntax check and unit tests on this copy. If any of the tests failed, commit would get rejected with results of the syntax checker or unit testing to provide feedback to developer making that commit. If syntax checker and unit tests passed, commit would get accepted. It worked but the trade off was that it made commits really slow. If code versioning software provided better integration to facilitate this other than running external programs on pre-commit, I think speed could be improved.
I'm looking for methods you've used to achieve this, thoughts on why this is a good or a bad idea, or experiences with code versioning tools that provide support for regression testing / build testing on code check in. Also how important is speed of commits to you?
Upvotes: 4
Views: 204
Reputation: 24723
You should be making use of some form of Continuous Integration where the environment is making use of Hudson, CruiseControl, or other tool to facilitate this behavior.
Upvotes: 6