Smalltalk - [VW] Automating builds with CruiseControl

Author

[VW] Automating builds with CruiseControl

Randy Coulman

2007-10-18, 4:25 am

I've written a series of blog posts on how we perform automated builds
of our VisualWorks-based software using CruiseControl
(cruisecontrol.sourceforge.net).

If you're interested, start here: http://tinyurl.com/2s4ud4 and work
your way forward.

Questions and comments are welcome.

Randy
--
Randy Coulman
NOTE: Reply-to: address is spam-guarded. Reassemble the following to
reply directly:
randy dot coulman _at_ gmail dot com

Tim M

2007-10-18, 8:13 am

Hi Randy,

> I've written a series of blog posts on how we perform automated builds
> of our VisualWorks-based software using CruiseControl
> (cruisecontrol.sourceforge.net).

Nice one - I'm a big fan of CI for Smalltalk as well so its nice to see someone
push the subject again (although I've often felt that while CruiseControl
is pretty good - its pretty complicated for what it does - having said that
I've been using CruiseControl.net with Dolphin although I just used Subversion
as my VCS so I didn't get into writing a plugin).

I notice that you mentioned that you have to use subversion anyway for your
non-ST artifacts - I find it very annoying that most of the Smalltalk vendors
put us in that position - IMHO its ridiculous that you end up having to use
several vcs's to store all the artifacts for your single project (I believe
Cincom is considering this - I wish they would move to Bazaar or Mercurial
so we just had a single set of standard tools to use for version control
- or let us store other files in their vcs and provide enough tools for other
team members to diff in things like Photoshop).

I was also curious that you mentioned that you turn off transcript logging?
In my implmentation I capture the transcript log and check it for any errors
or warnings - this in turn fails my build (e.g. I didn't checkin a pre-req
package). How do you handle this?

Finally - I didn't find it clear from your description if you are building
these images on a separate machine to check if "the build is broken". E.g.
are all your team members running CCTray (the little tray application that
pops up a message if the build breaks) - or do you have a lava lamp bubbling
away to warn everyone? This is the best bit of doing all of this work - as
it gets a real quality feeling on your team.

Anyway - thanks for the writeup

Tim

Randy Coulman

2007-10-18, 7:13 pm

Tim M wrote:
>
> I was also curious that you mentioned that you turn off transcript
> logging? In my implmentation I capture the transcript log and check it
> for any errors or warnings - this in turn fails my build (e.g. I didn't
> checkin a pre-req package). How do you handle this?
>

We just turn off the logging for the "modification check" part of the
process, not for all of the stages. That said, we tend to have a lot of
transcript logging in our system, which we log to a file at runtime, so
checking it for errors or warnings would be an interesting task. We
tend to rely more on our test suite to catch stuff like that.

> Finally - I didn't find it clear from your description if you are
> building these images on a separate machine to check if "the build is
> broken". E.g. are all your team members running CCTray (the little tray
> application that pops up a message if the build breaks) - or do you have
> a lava lamp bubbling away to warn everyone? This is the best bit of
> doing all of this work - as it gets a real quality feeling on your team.
>

We have a build machine that runs these builds, and it sends us all an
e-mail after every build (successful or otherwise). So, yes, we get
right onto broken builds, and we do get that quality feel for all the
parts of our system.

Randy
--
Randy Coulman
NOTE: Reply-to: address is spam-guarded. Reassemble the following to
reply directly:
randy dot coulman _at_ gmail dot com

Sponsored Links