Sigh – a Process Architect’s work is never done (in some cases it’s never even started). The same unyielding forces that bring about change in development technologies are also at play in the processes we use to develop. It has been four years since DSI started to change the way we develop software. While the principles that underpinned those changes have not changed much, if at all, some of the tools we use to support those principles are in need of updating or replacing.
Over the next few weeks and months I’ll be blogging in more detail about the latest set of changes we’re making. Right now, I can give an outline of where we’re going. Some changes are predictable and conform to industry trends. Others are more original and might even set a trend themselves:
- Switching to Maven2 as a build management tool.
- Introducing the concept of Continuous Performance Management into our CI process.
- Moving to Task-Centric development using Mylyn.
- Making the company dashboard richer by integrating our Atlassian tools more deeply
Continuous Performance Management
Happily, there is no need for me to make the case for Continuous Integration here. The advantages of discovering potential problems as early as possible are clear to most practicioners by now. The only remaining question about CI is how much more can we automate, how much more can we integrate into our CI builds.
In October of 2007, DSI launched its Application Performance Managment (APM) service in partnership with Quest Software (the folks who brought you JProbe and PerformaSure). An unexpected product of this relationship is something that we’re calling Continuous Performance Management – a tool to harness the analytical power of JProbe as part of Continuous Integration.
JProbe is a performance workhorse – it shines a light deep into running code and shows up potential bottlenecks and opportunities to improve its performance. However, like many powerful tools, it can take a while to crank it up and direct it into every corner of your code. This kind of labour-intensive task is the perfect candidate to automate as part of Continuous Integration – which is what Jason Barry here in DSI has been working on recently.
We’re switching our CI engine to Atlassian’s Bamboo, and so the moment is just right for us to start using CPM as part of our own CI activities. Now, on top of the normal checks on our unit tests, CPM will track their performance profiles over multiple builds and flag when those profiles move beyond a specified range.
The advantages are twofold: Firstly, the effort of using JProbe is sharply reduced through automation. Secondly, when a performance issue comes to light, it does so with respect to a very small and precisely indicated section of code – whatever the unit test covered. This second point is important because when analyzing code for performance issues, most of the time one spends doing this is spent searching for bottleneck, and relatively little time fixing them.
Here are a few screenshots of the CPM tool as it currently runs:
Next time I’ll be back with some thoughts on Maven – though I may have to ask for permission to swear. And as the weeks proceed I’ll also report back on our progress with CPM, on Task-Centric development and our experience with Bamboo and integration with the other Atlassian tools.