Financial Services Build Strategy

The Financial Services (FS) practice at Intelliware has just recently implemented a new build strategy. The motivation for this new strategy is based on the following:

  • Large number of FS Commons eclipse projects which consist of
    • basic utilities
    • hibernate and database utilities
    • common web components
    • testing frameworks for both unit and integration testing
    • build utilities
    • project report generators and publishing tools
  • Increasing number of FS clients that can take advantage of the FS commons
  • Requirement for more efficient builds and a faster feedback loop for the developers
  • Faster/Easier project setup and maintenance
  • Ensure that current development process and freedom is not affected

The Build

With > 10 FS Commons eclipse projects to date we need an efficient way to manage and package them. We considered Maven as an approach but quickly concluded that it did not fit our development process. We may introduce Maven at some point but we are not sure where it fits.

We have built a mechanism that allows us to control our build via eclipse settings. Developers work in eclipse and checkout projects based on their requirements without having to conform with an external dependency specification. Essentially we made the build reflect our eclipse project dependencies rather than seeding eclipse from another build tool such as Maven. Developers can easily change dependencies without worrying about the updating the build and at the same time make changes to shared projects without adversly impacting others.

We now use Hudson to manage our builds. Hudson gives us a much improved UI and better API. It has features to take advantage of multiple machines but we do not need to use this feature as of yet. Essentially we have built our own FS Project Builder that allows us to look into an eclipse project and determine the dependency graph and thus manage the build. A set of eclipse projects at a particular point in time (cvs commit) are compiled, packaged, and tested as a single build. The developers can make changes to any/all projects in a single checkin without any adverse affects to the build. This makes it very easy to add and remove projects.

Our FS Project Builder takes advantage of multi-core machines and breaks the build apart into tasks that can be run concurrently. For example:

  • ‘B’ and ‘C’ depend on ‘A’
  • The compiling of ‘B’ and ‘C’ can begin once the compiling of ‘A’ is complete.
  • ‘A’ can run unit tests while ‘B’ and ‘C’ are compiling

In fact we have broken down each project build into small tasks so we can maximize efficiency of the build. Initial results show a build time savings of >30% with more savings to come. Combine this with our multi-threaded unit and integration tests and we actually start to maximize our machine resources. Imagine when we take advantage of multiple machines!


It's only fair to share...
Share on Facebook
Tweet about this on Twitter
Share on LinkedIn

Leave a Reply