ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott Francis" <scott.fran...@newisys.com>
Subject RE: Looking for a Build Philosophy
Date Thu, 17 Oct 2002 18:50:53 GMT
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

-----Original Message-----
From: Malik, Yousuff [mailto:YMalik@erac.com]
Sent: Thursday, October 17, 2002 1:28 PM
To: 'ant-user@jakarta.apache.org'
Subject: 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: 'ant-user@jakarta.apache.org'
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>


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