Reproducible releases using Ivy, Ant and CVS.

Matthias Kilian
20070827

Note to the reader: for now, this is just a slightly modified copy of an email I sent to the ivy-user mailinglist. However, I'll update it on occasion to make a small article of it. The original mail is always available at MARC.

Oh, and of course here's the link to the Ivy homepage.

If you don't like green on black, just read the plain text version of this page.

You can send any feedback and/or corrections to kili@outback.escape.de. Please use a meaningful subject and avoid HTML emails, else chances are good that your email will end up in my spam folder.


On Fri, Aug 24, 2007 at 03:03:49AM -0700, bhatia wrote:

  > How do we work in the Ivy world ? Checkout a project from CVS, compile it
  > thanks to IvyDE by retrieving dependencies, make changes to it in the local
  > workspace, then what ??? publish it with changes to the ivy repository with
  > rev="CURRENT"... ?? Same logic for the branch ? And when I am ready to
  > commit and tag on a branch, I publish the branch with rev="my-branch-tag" ?

So, since Xavier wrote that a little survey would be welcome, and since this survey may answer your questions, here's what we do. YMMV.

(Assuming development on the HEAD trunk for now, I'll describe when and how we deal with branches in a minute)

That's all for releases on the HEAD trunk. When we need a hotfix for an older revision (which happens quite often, since we're not supposed to deploy our latest and greatest features without lots of testing on dedicated QA machines), we proceed as following:

This gives absolutely reproducible results, which is especially important when you've rather long development cycles with the need of beeing able to reproduce builds from several months ago to apply bug fixes to them. One caveat when using branches for hotfixes like we do: if you bump some dependency to a newer revision, double-check wether all other dependencies are still at the correct revisions; you may have to use force="true" on some dependencies. For example:

What's still on my TODO list are the mentioned integration and milestone builds and a better integration of ivy and cruisecontrol (or any other CI-like system).

Milestone builds would be nice, since we could test them on the QA machines and then, if everything is ok, switch them from milestone to release status, using the same mechanism as above. Unfortunately, there're also some problems, since we deploy on WebSphere Application Server, but we don't put EJB and resource bindings into our builds, so this is kind of error-prone, and it's more safe to just copy the tested applications from QA to the production machines.

I'm also planning to support pure integration builds on the CI machine, so tightly coupled projects will be tested without having to make and tag a new release all time.

Oh, and one final remark: NEVER EVER ship code built only in your IDE. It's not reproducible. I've even seen projects that were not buildable on any except a single developer's machine. Even if IvyDE helps a lot, there may still be problems, like a forgotten commits, different locale settings, or just sloppy developers not caring at all about quality. So, ALWAYS use a dedicated build machine that ONLY builds, tags and publishes releases.

Ciao,

Kili


Powered by txt2tags -- Valid HTML 4.0 -- Valid CSS -- Valid ASCII -- Source of this page -- Back to dead-parrot.de