One-click deploy/configure for J2EE stack
Posted by skelter Tue, 28 Oct 2008 03:24:00 GMT
Today was supposed to be get-home-early-and-stirfry-pork-broccoli.
I’m working on a new deploy mechanism. We have 20-25 servers that we need to be able to one-click-install-and-configure the front two-thirds of a J2EE software stack, including IIS->Resin running on Windows, JBoss on Linux. My predecessor has a mouse-trap-game of ant scripts involving telnet to do it. “As long as nothing goes wrong, it works every time.”
I started off with a verification mechanism so that once everything is up, the stack can self-check. Now I’m working on a mechanism to reliably update from version control, and run scripts and save the logs so we can A) detect when something goes wrong and B) what went wrong. The end result app will be kind of like a dashboard for 25 cars.
Just as my day starts to wrap up, something I worked on a couple of months ago blew up. Now that we have the capability to run our builds so quickly, a new trend has started: running more than one build at the same time on the same machine. This means that JUnit tests that open temp files in the temp directory collide with each other. Well, I wrote a utility a while back to help dodge that. It wasn’t a complete fix; it was just unlikely…very unlikely, to happen. Except when you are running enough builds that the number of dice you roll overwhelms the randomness of the dice. This was already supposed to be unlikely. Every once in a while, two copies of the same tests come up with the same random directory number, even with a test-specific prefix. So I spent an hour with the guy who ran into it, or rather had it dropped in his lap, writing a mechanism that actually exclusively locks access (native io) to the temporary working directory created in the temp directory for the test. We’ll see if it works tomorrow.
Dinner was late.