DeCare Systems Ireland Blog

I was very much taken by a discussion, “Continuous Integration: Was Fowler Wrong”, I recently came across on the TheServerSide.com, It was most interesting to read the diversified opinions on the definition of Continuous Integration (CI), and the relative significance of compiling vs testing, and where these two practices sit in the CI world. While I do not wish to join the debate as played out on the TSS, it did spark a train of thought about how this debate, in my opinion, is simply a symptom of the diversified nature of CI, and by extension, how the various views expressed are all valid. Different practitioners of CI emphasise the components of CI that matter most to them. Developments here in DSI, where we have moulded our own CI process over time, are another example of how the original idea of CI has evolved, to the point where it now incorporates altogether different software developments practices.

Let me explain further by mention of the forthcoming release of the ‘CPM Toolkit’, an extension to Quest Software’s Java profiling tool JProbe, that automates the collection of performance data from JProbes’ Analysis Engines and generates benchmarks on which to base an application’s performance.

You will find frequent mention of various CI aspects on DSI’s blog, so I need not rehearse the arguments of its importance within this company - suffice to say it is a central component to how we deliver software. To date, our CI process has been built on three fundamental building blocks; continuous builds, unit tests and code reviews. In parallel to this process, we have had more than a passing interest in Application Performance Management. What we have recently built in the CPM Toolkit, is a product which incorporates performance management within our CI process. What this means is that our CI process has evolved from its original format, to incorporate the altogether different focus of Application Performance Management.

The concept of APM is not new; simply take a look at this article dating back over five years to see that. Simultaneously CI as a concept has been around for many years now (it was referenced in Beck’s book Extreme Programming Explained written in 1999). But what the CPM Toolkit does is that it marries the two concepts together by providing a performance dimension to the existing CI process.

One of the main benefits of the CPM Toolkit, is that it overcomes the difficulties as posed by another software development phenomenon, namely premature optimisation. It achieves this by focusing attention on performance tuning early in the development process, but not in a way that would be considered expensive or excessively time consuming as is associated with premature optimisation. In case you feel a little lost - yes I did say that by addressing performance at the earliest stages of development you can overcome the problems which are associated with the very same thing! Let me explain this contradiction in terms. The CPM Toolkit is designed to run in the background, in a non-intrusive manner, e.g. as part of a nightly build, the CPM Toolkit profiles your application and gradually adds to that profile over time, alerting the user to deviations in application behaviour. What this allows the user to do is perform a trace back on how code changes impact on their application’s performance. By doing so in an automated manner, developers need only focus their time on performance enhancements when a noticeable deviation has been detected, thus avoiding the time spent chasing down blind alleys looking for non-existent performance problems! By using the CPM Toolkit, these performance problems are highlighted, and secondly it has the significant capacity to isolate the problem to a precise area of code, i.e. a particular unit test. This is a significant time, and ultimately cost saver.

Now, let me return to my original point, and the debate over CI’s definition. CI can indeed mean different things to different people. We in DSI have taken the view that we can build on our implementation of CI by developing a product that addresses a separate area of attention, namely APM. Judging from the TSS debate, I feel that other practitioners of CI have taken similar paths, thus while we all may have started out at the same point, CI has evolved over time to now incorporate tools such as the CPM Toolkit. I dare say that by introducing a performance dimension to CI a whole new definition debate may start!