Alex, Can you share more about how you operate this testing machine? Does this machine do automatic daily testing? how do you control it? Is it cron/bash based? I am working on a web application. Would it be possible to port my PHP unit tests and Selenium integration tests? I am very interested in your process. Craig, if you have a process, I am also interested in yours as well. Thanks, Eric On Fri, Mar 12, 2010 at 8:03 AM, Alex Dean wrote: > > On Mar 11, 2010, at 8:04 PM, Craig White wrote: > > On Thu, 2010-03-11 at 19:53 -0600, Alex Dean wrote: >> >>> On Mar 11, 2010, at 4:08 PM, Craig White wrote: >>> >>> On Thu, 2010-03-11 at 14:47 -0700, Eric Cope wrote: >>>> >>>>> It needs to be deployed to Linux and Windows. I can't just tar /dir >>>>> because I have .svn files I don't want to include as well as test >>>>> directories. I planned on using a form of tar/zip. >>>>> >>>>> ---- >>>> ignoring that this really should have been on the development mail >>>> list... >>>> >>>> svn help export >>>> >>>> I can't imagine a single good reason for using an existing directory >>>> instead of exporting specific 'tags' from svn and using that for >>>> packaging except that there really wasn't much understanding and >>>> planning in svn. >>>> >>> >>> Can't speak for anyone else, but at least in my case I think there was >>> quite a lot of understanding and planning. >>> >>> If the build machine already has a recent working copy of the branch >>> you want to build, switching to a different branch or getting the last >>> bug fix with 'svn up' or 'svn switch' is a lot simpler and faster than >>> getting another full 'svn export'. >>> >> ---- >> I tend to think bigger picture and don't resort to simplifications just >> because they are simpler or faster. >> > > Now really, that's a self-serving assertion if ever I've read one. I don't > think I've 'resorted' to anything. My company has a process that works > quite well for us, and I shared it. You're free to disagree, and I welcome > the discussion, but your choice of words is unhelpful. > > > >> Reasons that come immediately to my mind to only use an svn export (from >> a specific 'tag': >> >> - stability - you can always see what was packaged by doing a checkout >> in another directory or on another computer. >> > > You can do that with just a revision number. You don't need a tag. If you > like to use tags, that's of course fine, but all the points you make are > satisfied just by knowing a branch and revision number. > > Don't misunderstand. The working copies we do builds from have no local > modifications. I'm not talking about a developer doing a build on his local > machine from a working copy which is also used for development. That's not > the case. I'm talking about machines which are dedicated to doing nothing > but builds, and have working copies of release branches. But if you just > built r10198, and some last-minute bugs were found and fixed in r10199, it's > much faster (and no less accurate or repeatable) to 'svn up' rather than > doing another 'svn export'. > > This is a common pattern for integrating cruisecontrol.rb with subversion. > You keep a local working copy on the test machine. Nobody makes > modifications to it, it's just a local cache of the software under test. > Every time a new revision is detected, CC runs 'svn up' and re-runs all the > unit tests. You get results fast, and developers know quickly if something > they've done has broken a test. > > > >> There's a reason that management systems and practices are developed and >> rarely do they focus on simpler or faster. >> > > You speak of 'management systems and practices' as if that were some > monolithic thing. This is a vast oversimplification of a complex topic. > > Further, emphasizing process simplicity and speed (while maintaining > repeatability, of course) is quite legitimate. Complex and unnecessarily > time-consuming processes are those which encourage mistakes and increase > expenses. The whole agile approach to software is about making the process > simpler and faster, while improving quality and value. > > alex > > --------------------------------------------------- > PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us > To subscribe, unsubscribe, or to change your mail settings: > http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss >