On Fri, 31 Dec 2004 13:26:51 +0100, Vincent Massol <[EMAIL PROTECTED]> wrote:
> We do use this practice. But the issue I am trying to solve is not the > coexistence of developers and integrators. It's the coexistence of > developers. We've not succeeded in stabilizing the build for lots of reason > (one reason is that we've not been working hard enough to reduce the build > breakage reasons. One reason is that management is not willing to replace > existing tools that do not help - Example: StarTeam (SCM) does not show you > the file you have added to a new directory. Thus when you commit, developers > systematically forget those files as they do not appear in the StarTeam's > view). I guess I don't see the value of a 'pre commit' asynch build and test over a pre-commit DEVELOPER initiated Private System Build. As Dominic said, making the process asynchronous doesn't help all that much... I guess my thought is that if it /is/ asnychronous, you may as well do it post checkin, since the developer has already "tossed the code over the wall..." I really don't see the value of the "pre-commit automated build and test" approach over the following: =Developer makes changes, runs unit tests. = Developer resynchs their PRivate Workspace with the Active Development Line = Developer does a Private System Build and Smoke test (and does not check in code until the tests pass). If the developer's don't care enough to do this, all is lost anyway... = Developer checks in code = An automated process checks out the latest Active Development Line and runs a more thorough set of tests. Keep in mind that even with each developer doing a pre-commit test, you can still end up with a broken codeline if 2 developers do incompatible changes out of phase... so you may as well acknowledge this and do the full tests on the checked in code. Automation is good to remove tedium, but automation can't make up for lack of care. Write a script to do the pre-checkin process in the developer's workspace. Perhaps you can even set up some sort of tricky protocol so that the developer can't check in a change unless they have run the build/tests (I have some ideas for this, but that would take us off track). But the precommit testing should be done by the developer in the developer's workspace. And once the developer hands off their changes, they should check them in. -Steve -- Steve Berczuk | [EMAIL PROTECTED] | http://www.berczuk.com SCM Patterns: Effective Teamwork, Practical Integration www.scmpatterns.com To Post a message, send it to: [EMAIL PROTECTED] To Unsubscribe, send a blank message to: [EMAIL PROTECTED] ad-free courtesy of objectmentor.com Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/extremeprogramming/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
