ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Malik, Yousuff" <>
Subject RE: Looking for a Build Philosophy
Date Thu, 17 Oct 2002 18:18:17 GMT
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
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


-----Original Message-----
From: David McTavish []
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).


-----Original Message-----
From: Unchis, Debra []
Sent: Thursday, October 17, 2002 1:55 PM
To: ''
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.

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message