Catalyst Development

As a software developer, most of your time is spent creating, maintaining and debugging code. However, one of the aspects of development that is often overlooked is the actual build process itself. Of course, we all build projects from the IDE, but when it comes to production releases many developers — particularly those working on smaller projects — just follow the path of least resistance and do what is easiest at the time to get the product built and out the door. In the beginning, that often means manually compiling and copying files or creating a few batch files to do the job. The problem is, although that approach can be convenient at first, it is also prone to error and quickly becomes time consuming even for a small project. And the larger and more complex your build process becomes, managing multiple makefiles, batch files and scripts become even more unwieldy.

SocketTools is a fairly large collection of components and libraries. We support a number of different development tools and frameworks, and over the years the build process became fairly complex. When the first version of SocketTools was released in 1996, it consisted of Visual Basic components and the build process was comparatively simple. We used batch files to build the components, and manually built the help files and install package. Over the years, as development tools evolved and our product line grew, our build process really didn’t follow suit. We just kept on adding batch files, created some custom makefiles and wrote a few Perl scripts to manage the build process. At last count, we had about 18 batch files, three Perl scripts and custom makefiles for each product group. While the build process worked, it was difficult to manage and maintain.

During the development of SocketTools 5.0, we decided to review our build process and make some changes. The most important criteria for us were:

1. Fully automated process, requiring no manual intervention
2. Structure the build process based on product groups
3. Support for external command line utilities
4. Support for multiple build configurations and options
5. Complete logging of the build process.

The first criteria was pretty much a given, but the idea was that we wanted to fully automate absolutely every part of the build process. At the push of a button, we wanted to be able to go from project source and documentation to a finished product, down to the executable installation package which would be uploaded to our servers. We also needed to be able to structure the build process based on our different products, and support different build options.

After doing some research, and contemplating building our own in-house tools, we decided that the tool which best met our needs was Visual Build from Kinook Software. Using Visual Build, we were able to completely automate the build process from start to finish, and it supports a hierarchical build structure that we needed to manage the various product groups within SocketTools. It has the ability to run any external command, but goes beyond that with the ability to create macros, invoke scripts, transfer files and a lot more. The actual build process itself was extremely easy to setup, and the build configuration is stored as an XML file which was a significant plus for us because it allowed us to create a build framework, edit it manually in a text editor and tweak it outside of Visual Build itself.

It did take some time to convert everything from our mass of batch files and scripts, but the end result has been a build process that is infinitely easier to manage and one that feels much more solid and reliable. If you’re a Windows developer, I strongly recommend that you take a look at Visual Build, download the evaluation and give it a try. Once you start using it, you’ll never want to build your software any other way.