ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chappell, Simon P" <>
Subject RE: Looking for a Build Philosophy
Date Thu, 17 Oct 2002 19:08:35 GMT

>-----Original Message-----
>From: Scott Francis []
>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.

Agreed. This is a great discussion.

>1)  First off without managerial support you will not be able 
>to achieve any type of build management.  If you have 

Sure you can. I'm not a manager, but by pointing out the benefits of regular integration and
builds, I got developer buy-in.

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

Ouch! I know that we had to bring in treats if we broke the build, but that was in fun. Your
suggestion doesn't sound like fun to me.

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

Agreed. Hence we maintained a separate integration area. Just because it built in your sandbox,
I won't believe that it truely builds until I see it compile in my integration area.

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

Automated nightly builds are great, but the next best thing is running one each morning. Thankfully,
our system had no EJBs and built quite quickly.

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

That was me. As technical lead, it was my job to make unpopular decisions anyway.

>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 

Agreed. We did that too.

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

Oops. I forgot to look sad all the time. ;-)



Simon P. Chappell           
Java Programming Specialist            
Lands' End, Inc.                                   (608) 935-4526

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

View raw message