One of my areas of interest over the last 6 months at work has been in creating a build and deploy system. We use Maven and CVS exclusively and our admins, who remain the only ones with production passwords, are not particularly Java savvy.
Thus was born first ‘Portify’, then ‘Buildify’, then in union with the nightly-build system I wrote in the previous year, ‘Genesis’. I have permission to open source it, so can happily talk about it, though there’s one major reason for not doing so yet. It’s all in Bash currently 
I had some major aims:
1) Must be of use to developers for their Windows/whatever boxes, just as it is to the administered Linux servers. I hate that lessons learnt in one environment were not being shared, and that new developers were not able to be given a version of the product to start work on.
2) Builds an ‘application’, not just a bunch of wars etc. JBoss configuration, streamlining, lessons all get integrated into the application on each build and deploy. The bad side to this is that each application is 30Megs or so in size. A relatively, but not completely yet, stripped down JBoss. The aim is to have it work with any container, though JBoss 4, 2.4, stand-alone and oscube [an unreleased osjava container that sits on top of jndi] are likely to be the next to be tried.
3) Must be easy. Currently the process involves two top-level bash scripts, a directory move, scp of files, unzipping of said files and starting.
Of these, 2) is definitely the most arguable. Bear in mind, we don’t have Java admins who are writing their own Log4j evaluators and researching JBoss. It’s done by the developers. This helps to keep the production systems under control without giving developers production access.
All of this is based on CVS. An application is made up of many cvs modules, as defined in an application.desc file which maps a cvs module to a tag/branch, where HEAD is just an oddly named branch. In addition to building the code, which is done via a standard ‘maven clean genesis:build’, where genesis:build is a goal-link to whatever the real build-goal is, a ‘deps-zip’ goal is performed which collates all the dependencies that exist [outside of a war] according to a genesis.runtime property being true.
These are sucked together into a ‘conf/ deploy/ deps/ lib/’ structure for each application in a product. This is buildify at an end. These are then transferred to portify, which takes the build-elements and applies them to a container of some kind, ie) JBoss 3.2. At the same time, a target-environment .properties file is used to configure the container. These are then all zipped up.
Payload, an osjava release, http://www.osjava.org/payload, has been created to be used instead of the zip. It is a self-extracting jar which performs s+r on the files as they are extracted. This means that one portified container will be installable on many platforms, removing the worries of a QA/Staging build and a Production build being subtlely different.
Information about the applications, versions and configurations, are deployed as a part of the applications.
It’s been a very agile piece of work, with parts going into operation last October despite other parts only existing in my head. By putting those early pieces into active use as soon as possible, it helped shape the system. I largely did this by doing by hand what would one day be a script. Arranging build files instead of going directly from CVS.
The admins will get to use it for the next project that starts imminently, so I expect some grumbles there. 3 other developers have been using it in the last month or two, so hopefully most are dealt with.
My next decisions are where to go next. The payload part needs applying, and I need to port it to a platform-independent language. I had always planned to write it in Ant, but Groovy is very tempting too. It could just all end up written in Java too, though a scripting language seems a better fit.
Why this ramble? Because I can. By which I mean, because it’s something at work that is open sourceable, and unlike Scraping-Engine or ReportRunner [other ideas at work that are available to open source when I find time], will not suffer when business directions change.
