Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [wtp-dev] Stability of I-builds during release shutdown

We have very good experience with a tool called CruiseControl (http://cruisecontrol.sourceforge.net/) which nicely automates head/map types of builds (i.e. "build whenever there are changes"). CruiseControl is straightforward to setup and I can help doing that if WTP team is interested.

--
Regards,
Igor Fedorenko
Provisioning & Orchestration Development
IBM Tivoli Toronto
igorf@xxxxxxxxxx
Office (905) 413-3748

Ted Bashor wrote:
Drawing from what others have said, here are my thoughts on improving
the build process.

Some assumptions, please set me straight if I'm off base: 1) In
principal, changes should not be released to the map files if they
cause compilation errors in any WTP components or cause any JUnit
failures.  The "nightly" build from head should be used to check for
compilation and test failures if you are not building and running
tests yourself. 2) Declaration of I-builds currently involves a fair
amount of manual smoke testing and subjective approval. 3) Builds
from head and from the map files can be scheduled/automated.  (Naci,
David, how much manual work are you doing when you "re-spin" an
I-build from map files?) 4) Update of the website with the latest
build from head or map files can be automated.

Given that, I'd propose we have four types of build in the short
term, with the goal of going down to three as our automated test
coverage improves.

1) Head build:  Peformed as frequently as possible, somewhere in the
every 4 to 12 hour range (thus "nightly" is kind of misnomer).  The
website only maintains the last 1+ head builds  (perhaps you can only
download the last head build zip, but view stats for the last N head
builds?).  It is acceptable to check in changes that cause
compilation and test errors in the head build, it's assumed that you
are in the process of integrating with other components, fixing up
tests, etc.

2) Map build:  Performed as frequently as possible, also in the every
4 to 12 hour range.  As with head builds, the website maintains the
last 1+ Map builds as space allows.  Causing compilation or test
errors in a Map build is unacceptable - you should have waited for a
head build pick up your changes and verify no compilation or test
errors before releasing the change.  I'd recommend that a breakage
mail goes to wtp-dev to "encourage" compliance.  Compilation
breakages of Map builds are expected to be fixed immediately, test
breakages might get a few hours grace period.

3) Integration build:  This is a map build that has zero compile or
automated test errors that has "blessed" via some amount of manual
testing.  Because producing this build requires manual certification,
it can only be achieved every couple weeks.  But note that the only
reason we have an Integration build at all is because the automated
test suite isn't rich enough yet.  In theory, as the test suite
matures, this type of build would be obsolete.  Teams wishing to
adopt a pre-Milestone build would simply take the most recent Map
build, which we continuously strive to keep error free.

4) Milestone/RC build:  A blessed map build that has achieved some
level of functionality.  Once every 6 weeks or so.

So I agree with both Thomas' point that we need a map-based build
containing released changes much more frequently.  And with Naci's
point that we should be decreasing the frequency of I builds because
they are labor intensive.

I think the only thing we are lacking are continous Map builds, and
stricter enforcement of breakage policy for these builds.

-Ted





Back to the top