quantlib.co.uk

Software development is iterative and incremental. Therefore a critical part of building a successful production system is the build and release process. The faster we can build, test, and release, the faster we can iterate through development landmarks. This is of no use if we are not sure that everything we have done before is still working as required, which is enforced through test-driven development with automated testing.

Source Control

All library code has to be safely stored and versioned. Using a professional source control system is essential. This enables particular snapshots of the code to be labelled, or versioned, which is required for patch releases for fixing bugs, and for returning to a known previous version. A properly supported source control process will also ensure all work is backed up regularly.

Particular source control systems include packages such as Microsoft Visual Source Safe (to be replaced by Microsoft Visual Studio Team Foundation Server), Subversion, CVS, Clearcase and Perforce. These systems vary in their scalability, and ability to work across multiple geographic locations.

Build

An automated build and test system will improve code quality and reliability greatly. A tool such as Cruise Control can be configured to automatically check out the code from source control, build it, test it, and deploy it. Cruise Control can call a build tool such as Ant, Nant, Make or MSBuild.

A proven set-up is to do a full build (including tests), having deleted all intermediate files and directories, once a day, overnight. Then, during the day an incremental build can be done every hour, or when some code has been checked in. If the build, or a test, fails then emails are sent to the developers immediately, and the problem quickly rectified.

It must be possible to build and run the library both in debug and release. Care must be taken to ensure that tests pass in both debug and release. However, debug can be too slow to test some numerical problems.

Configuration

It is extremely useful to be able to update configuration dynamically, without recompiling. There is no need to recompile the code just to update the holiday calendars. The same goes for market conventions, which rarely change, but should be loaded dynamically from a file or web location. It should be possible to add the defaults for a new currency without requiring a new library release. Being able to change configuration parameters, such as default algorithms, or tolerances, can be useful when debugging a problem on a trader’s desk.

The exception is the version number, which should be compiled into the library. Otherwise there is a chance that any configuration files may get separated, or fail to be overwritten, and inconsistencies introduced. This is also an argument for deploying a single dll, rather than many.

Testing

Testing should happen constantly. We focus on two main types of testing, regression tests and unit tests. Regression tests exercise the interface to the outside world, and ensure that results do not change between library versions. Unit tests are low level and test the functionality of a single class or function. C++ testing frameworks are available from Boost or CppUnit.

There are now tools for many languages that generate test cases, and report which areas of the code are not covered by any tests. However, the tools available for C++ are much inferior to those for .NET or Java.

A quantitative library will probably also need to have a regression test suite to run Excel spreadsheets. In principle Excel regression tests should also be automated.

Release

No developer wants to spend time building a release manually, even so, much time is wasted releasing code. This implies that the release process should be completely automated, so it takes no time away from developers.

Release as a single zip, labeled with the date and release version. If releasing an XLL then it should be possible to start on any machine by double-clicking. It should not be necessary to change the registry settings for the machine, add environment variables, or modify the path. All these factors take developer time and increase the chance of mistakes.

Client Systems

If any systems have a dependency on the analytics library they should be tied to a release schedule. This prevents large gaps of six months or a year between integrations. In this time many things change and the amount of work needed to integrate increases greatly. The main overnight system is always under development, so should integrate analytics releases once a month. Other applications that depend on stable core analytics may only need to integrate every three months.