Development Automation

The second beta of LicenseKeeper 1.3 was just released to testers this morning.

Running a beta test cycle at the end of the year is a bit rough. People aren’t at their computers. Instead, they are spending time with friends and family. Luckily, a few people have been running the beta and reporting issues. But, I can always use more testers.

If you would like to help out with testing and get an early look at what’s in the next version of LicenseKeeper, sign up on the LicenseKeeper Beta Mailing List

Automating the Development Process

For those of you that are developers or are interested in the inner workings of the development process, I’m trying something new with this release.

Since the start of LicenseKeeper development I’ve been meaning to automate the process of testing and packaging releases. But, I was focused on development and just brute forced my way through these things. As expected, I stumbled a few times which resulted in some embarrassing moments.

Automated Builds and Packaging

With the extended beta cycle due to the holidays, I took the time to get these items implemented into my process. This beta release is the first LicenseKeeper release to have been built and packaged through an automated process.

While the script that automated this work is relatively simple, it ensures that everything that needs to take place does so. Manually building and packaging software can be time consuming and error prone due to all the steps involved. Now, I just kick off one shell script and everything gets done in the correct order.

Automated Testing

Additionally, LicenseKeeper now has a full suite of unit tests for the serial number scanning. This part of LicenseKeeper began as a pretty simple chunk of code. As people reported email formats that the scanner could not read or parse, the code was updated. Over time this code has become quite complex and hard to test manually.

So, I added a suite of unit tests that run through a large set of test emails in various formats to ensure that they are all scanned correctly. Now when a change is made, I can run the tests and instantly see if any of the known email formats break.

If someone reports an email format that doesn’t work, I simply create a new test and adjust the code. This serves as a great way to ensure I don’t break anything going forward and provides a simple method for documenting what email formats the scanner supports.

ZIPs vs DMGs

Also new with this release is a move away from the traditional Disk Image or DMG distribution package. While I haven’t had the DMG related support issues that many other developers have suffered through, they are a pain to deal with on the creation side.

Yes, there are several products and methods for dealing with the creation of DMGs and I did try to incorporate several into my automated build process. But while trying to crowbar this into my build script, I took a step back and asked myself what benefit the DMG was providing over a simple ZIP file. I couldn’t come up with any reasons to keep using the DMG.

Mac OS X automatically uncompresses ZIPs when downloaded and cleans them up for you. There is no need to copy the application out of them in order to get work done or eject them to clean up your desktop. Plus, I don’t have to spend time and resources on trying to get my DMG background images to reliably look good under Tiger and Leopard.

Decision made. Starting with version 1.3, LicenseKeeper will be distributed using the ZIP format.



, , ,




One response to “Development Automation”

  1. Dan Grover Avatar

    I decided the same thing with ShoveBox — couldn’t figure out why we have this tradition of putting things in DMGs.

    I think it mighta started with system updates on OS 9, when there was an occasional legitimate need for installer-y things to run off their own volumes even when not distributed as physical media. Dunno, though.