On Thu, 30 Dec 2004 13:47:23 -0500, Ron Jeffries <[EMAIL PROTECTED]> wrote: > > On Thursday, December 30, 2004, at 12:45:15 PM, Jason Yip wrote: > > I also have an assumption about staging the "safety nets", if you > > will. Immediate group of unit tests for the current feature should > > run in at most 2 seconds, pre-commit (aka Private Sandbox) build > > should be < 5 minutes (ideally less than two), post-commit full build > > falls into the Ten Minute Build (at most) practice. There may be more > > staging depending on how complicated the deployment environment is. > > > Every time there is a failure, we learn to add something to the > > previous faster-running stage. > > If it works, do it. And write it up.
This is basically the idea behind the dependency structure in the SCM pattern language between Private System Builds, Integration Builds, and the various kinds of tests. http://www.scmpatterns.com/book/pattern-summary.html or http://www.scmpatterns.com/book/refcard.html with the emphasis on more frequent integration, perhaps at the expense of "better" yet longer running tests.... (Note, that I probably need to better define the distinction between smoke, unit, and regression tests) > The smaller the time-frame between commits, the more I'd like to > have an automated setup. //But I want one that pushes code to all > the other developers, keeping the sandboxes synchronized.// We've had this discussion before. The trick is to not be disruptive. I suspect ALERTING someone that there was a change should be good enough (and we all update from the repository every few minutes when we're not actively coding anyway, right ? ;) ) > I think that the manual check in is a team-building and > experience-building practice. A team with existing habits of > throwing their code at the build and waiting until Friday will, I > believe, do well to experience building, and its impact, directly, > hands on, before going to some automated scheme. > My reasons are primarily social, just as they are for wanting > planning done on cards rather than in a software tool. First I'd > like to get the society right, and all the automated things that > most pre-Agile developers have used have set up almost exactly the > wrong habits. There is a story in one of Gerry Weinberg's books (Psychology of Computer Programming?) where some programmers lamented the rise of Time Sharing Terminals because they would lose the chance to discuss their work w colleagues while in line for the card punch machine... This reminded me a bit of that... ;) I do agree that it is good to figure out what practices work and THEN to automate them... often people start with tools first... maybe it's a fascination with technology... -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/
