ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vishal_Santo...@gallup.com
Subject RE: Looking for a Build Philosophy
Date Thu, 17 Oct 2002 19:26:48 GMT
well we have a different approach....

we have an integration between checkins to cvs and ant ....
a checkin into a tagged module results in a build being launched 
(of course the developer who does the check in is listed)..
we build the whole system up for every chain ..(though that needs a
dedicated server)
we have the server where the cvs server resides ....
this is a combination of perl and java at it;s best ...
each developer who commits a felony is mailed immediately after he
commits(privided the build failed or the unittests)..
we wrote our own java code that integrated cvs with ant but sourceforge is
another 
solution...

what we desired was an immediate warning system that intsead of running as a
chron job
or as a scheduled event ... ran based on an event..
that event was a checkin...

well another addition to a very fine discussion...



-----Original Message-----
From: Dominique Devienne [mailto:DDevienne@lgc.com]
Sent: Thursday, October 17, 2002 2:09 PM
To: 'Ant Users List'
Subject: RE: Looking for a Build Philosophy


This gets my vote for the best post of the month if not year on that list.

Thanks Scott! ;-)

--DD

-----Original Message-----
From: Scott Francis [mailto:scott.francis@newisys.com] 
Sent: Thursday, October 17, 2002 1:51 PM
To: Ant Users List
Subject: RE: Looking for a Build Philosophy

Ok, there have been a lot of decent comments coming from the mailing list
but let me take things to a little higher level view.

1)  First off without managerial support you will not be able to achieve any
type of build management.  If you have developers who are used to doing
things a certain way (being however they feel like doing it that day), you
are going to be very hard pressed to get them to change.  That being said,
if you can get a change in place you must also have a system in which to
enforce and in some cases punish those that are violating the structure.
Without that good luck.  Have developer performance reviews be negatively
affected by habitual build breakers.

2)  All code must be properly built and unit tested prior to being checked
into the tree.  This should usually consist of taking a fresh pull of the
code base and overlaying the changed code (it's amazing how over people
forget that they changed these 1 or 2 files (especially header files) and do
not catch it because it "worked on my box" in their development
environment).

3)  Create a nightly build process.  This is one of the most valuable tools
that you have.  Testing and QA teams can update their image from successful
nightly builds.  Unsuccessful nightly builds can be given back to the
developers to determine why this was done and what the necessary fix is.

4)  Have a separate CM/Build person who is also responsible for creating the
development and release process.  By doing this, you are have someone who
will be willing to make the "unpopular" but "correct" decisions about how
things should be done.  Developers notoriously do not like creating Unit
Test plans or Release Notes.  Forcing this as exit criteria from the
development and entry criteria into the testing process helps grease these
wheels.

5)  Constantly look for ways to optimize and automate the process.  I
personally like to use an iterative approach with my duties.  Usually I'm
walking in as a configuration mgmt role that they have no semblance of a
process.  Triage is a highly effective skill when it comes to this.  First
thing I always do is automate the build.  Then throw it into a nightly.
Then look for inefficiencies within the build tree or directory structure.
Next round two of automation (automated testing/deployment).  All the while
constantly writing reams and reams of approach doc and process doc in order
to create the foundation of what I'm trying to get done.  As the system
becomes more and more automated...and the documentation on the process gets
more and more verbose, your job becomes infinitely easier.  New developers
can just RTFM and become product members of the development community.  The
automated processes make your life easier and give you more time to continue
to tighten down the hatches and explore new technologies that might make
your role even more fun and rewarding.

6)  If you are the build manager...make sure you never let anyone know how
much you like your job.  Most people in the organization take pity on us
because they don't think we enjoy our jobs.  Truth be told, I've had more
fun in CM then I ever thought possible.  It's a very flexible role that
allows you coding, process, and personal interaction on a day in day out
basis.  But at the same time, I'm more than happy to hear people lament on
how awful my job must be and how they are so happy that it's me an not them
in the role :)

Scott

--
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>


Mime
View raw message