Part 2: The First Piece of the Puzzle

Historically, TAF has handled builds by accumulating changes and performing a big integration at the end of the development cycle. As you can imagine, it’s a great demonstration of the benefits of continuous integration, although it’s marginally useful for those situations where a change needs to be deployed into production immediately. Since changes are always made on the code currently in production, no backporting is required. This one small benefit aside, however, the situation at TAF was screaming for continuous integration and builds to ensure that the developers were building on each other’s code changes.

It was well and good to say that we should do continuous integration with frequent packaging, but putting it into practice was a little more problematic. Trying to package sixteen or so images on even a daily would occupy someone’s time for half a day, not really providing any benefit for anyone. With a pending upgrade, we were faced with double that number, since we’d need to package for two versions of Smalltalk. It was obvious that an automated solution was needed, something that could run unattended overnight.

One problem immediately reared its ugly head: VA Smalltalk doesn’t really support scripting, never mind scripted builds, in any obvious fashion. In another life, we had gotten around this by creating a magic image that would load a particular config map and package, but I didn’t like this approach for a few reasons. First, I’d accidentally saved on top of the magic image too many times and had to restore it. Second, I had too many disparate images to want to create a magic image for each. Third, I really wanted to be able to start from a virgin image each time to ensure I had a known starting point.

Some enquires in the VA Support Forum led me to abt.cnf and some interesting possibilities.

Advertisements

2 Responses to “Part 2: The First Piece of the Puzzle”


  1. 1 Bob Hartwig 2011-03-29 at 16:21

    I’ve actually hacked up automated build scripts for VA that allow me to load specific config maps into fresh images, then package them into many different runtime images, all invoked from a single batch file.

    It entailed writing some minimal start-up code in the base image to detect a command line switch that points to a .st file. The .st file automates loading the top config map with dependents, or invoking the packager, then sending System exit to go back to the batch file.

    It’s not pretty, but it took a process that required several hours of error-prone manual operations, and made it into a single command that runs for a half-hour or so unattended. I can send you specifics if you’d like, but it’s for an old version of VAST (4.02b, using a 5.0 VM, which still works great on Windows Server 2008).

    • 2 koschate 2011-03-29 at 20:55

      What’s really sad is that so many people have gone to the effort of solving the same problem. One of the reasons I’ve put this code out there is so that we can all converge on a single solution. Ideally we can come up with a solution that will be incorporated into the standard product, and we can all get along with more interesting things.

      While I appreciate your offer, you should know that I started this effort over a year ago, and the solution I’m documenting here has been in production since last summer.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s





%d bloggers like this: