I had a couple of thoughts on this: [Background: I am the build, test, test-tools developer for our project]
1. Having worked somea as a developer has saved me a lot of work when the build breaks. Then I can submit targeted bugs like: two diferrent versions of log4j.jar are being used, circular dependency, etc. 2. I only rebuild my jars (and do an autocheckout/autocheckin) if the source code has changed using the uptodate tag [what a life saver!] 3. Each project can be built at its level as well as the root level. For build purposes I used the master build file which calls the subordinate projects' build files [inheritall="false" --- another beautiful util]. The developers use the appropriate build.xml files, and the requisite build.properties files to build their individual projects. Haneef Mohamed Group1 Software - Hotdata Austin Group [Acknowledgements: Joe Magdaleno, Ed French] -----Original Message----- From: Malik, Yousuff To: 'Ant Users List' Sent: 10/17/02 2:18 PM Subject: RE: Looking for a Build Philosophy Here are some of the best practices that I have found works 1)Nightly development and integration builds 2)You need to have different dev, int and QA branches. Clearcase is highy recommended. 3)Schedule the nightly builds on a cron job and if a compilation error occurs send out an email to the developers 4)Create a junit repeort and mail it to the developers 4)No compilation errors should occur in integration builds 5)The build master should "NEVER" be a developer. If so then he/she would find ways to fix compilation errors Let me know if you need more information Regards Yousuff -----Original Message----- From: David McTavish [mailto:dmctavish@;SANDVINE.com] Sent: Thursday, October 17, 2002 1:05 PM To: 'Ant Users List' Subject: RE: Looking for a Build Philosophy What I'd like to know is how often does your organization build? - nightly What events lead up to your builds? - every night, and major releases How involved are the individual developers? - limited in the build process, but empowered How do you progress from a unit test build to a system test build? - two distinct phases: - unit tests run nightly after build - system test runs in separate environment (test lab) that is an end-to-end testing suite developed in tcl. we are in the process of integrating this with our nightly build process. as far as having to run after errant code being applied to the build process, make sure you are using some form of cvs repository (we use Rational ClearCase (no endorsement)). if developers are caught checking in code that does not compile, they should be punished as such (ie: bring donuts/snacks/etc. for the rest of the team the following day). it shouldn't be the "build master" who manages the code base, but the developers. (although the build master is usually a developer too). d. -----Original Message----- From: Unchis, Debra [mailto:DUnchis@;coral-energy.com] Sent: Thursday, October 17, 2002 1:55 PM To: '[EMAIL PROTECTED]' Subject: Looking for a Build Philosophy Here's a change of pace question for the group... I am the Build Manager for my group. By "Build Manager" I mean I wrote the build.xml for our code, I don't have a full fledged background in what I'm calling "build philosophy". So I'm no expert here, I'm just trying to get an idea on how other organizations do it. Not the technical on internal aspects of the build (not the targets and tasks) but the PROCESS, the philosophy behind a build. I know there is no right or wrong, but I don't have any examples to follow so that's what I'm looking to this large pool of fellow builders for: I mean I'm sure this can be simplified to build when it's necessary or when changes are made, but I find on my project that we are building every night and I'm finding that I spend half of my day tracking down errors and rebuilding. I kind of think that's a waste, but I don't have any facts or examples to back me up. Management says "build", so I build, but there has to be a better SYSTEM out there. Can you all help me out with some real life experiences and advice? Thanks so much. Debbie -- To unsubscribe, e-mail: <mailto:ant-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:ant-user-help@;jakarta.apache.org> -- To unsubscribe, e-mail: <mailto:ant-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:ant-user-help@;jakarta.apache.org> -- To unsubscribe, e-mail: <mailto:ant-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:ant-user-help@;jakarta.apache.org> NOTICE: This E-mail may contain confidential information. If you are not the addressee or the intended recipient please do not read this E-mail and please immediately delete this e-mail message and any attachments from your workstation or network mail system. If you are the addressee or the intended recipient and you save or print a copy of this E-mail, please place it in an appropriate file, depending on whether confidential information is contained in the message.
