BAR-Tab: Fixing pain points

I'm reading "The Passionate Programmer" by Chad Fowler and one of the chapters in the book talks about standing out as a top performer at work by identifying pain points that your development team puts up with on a daily basis and making a plan to fix them.

As I've learnt, knowledge that's not put into practice is useless / unprofitable, so I examined the challenges and pain points that we face as a development team at the organization that I work for and one of the pain points I identified in my current role as a Websphere Message Broker developer is with the deployment mechanism.

Broker Archive (BAR) files are used to package code artifacts that were created by a WMB developer for deployment on a WMB Server. In addition to being a container for code artifacts, WMB also lets you override properties defined in the WMB code artifacts by specifying these overrides on configuration files contained in the BAR file. This scheme is great because it allows a developer deploy the same code artifacts to different environments, e.g. DEV, TEST, PROD without having to change the actual code. Configurable properties such as the database connections, log file location, queue names, etc., which may be different between the environments can be specified on the deployable artifact (BAR file) instead.

The issues our team has with the BAR deployment mechanism is with the tooling for it. The Websphere Message Broker Toolkit, which is Eclipse based, organizes all the configurable properties in a non-intuitive tree structure, which in combination with the sheer number of properties in a small WMB application, makes it very easy to miss setting a property. The result of this is that we have had several times when a WMB application gets deployed to production but has a property that the deployer missed that points to a test queue, datasource or log file. This can result in us having to back out that deployment or worse, not noticing it until there is an adverse effect in the production environment.

My solution to this problem was to create a tool which would interrogate a BAR file for all its relevant configurable properties and display them in a simple table structure. In addition, the tool would highlight properties that don't match what is expected for a particular environment. For example, if a BAR file is destined for a production server but has a property that points to a dev or test web service endpoint, that property would be highlighted. This makes it extremely easy for a deployer to spot a misconfigured property and take corrective actions.

In thinking of the best delivery vessel for this tool/service I decided an Eclipse plugin would be the best vessel. Since I'd never written an Eclipse plugin before, I had to learn how to write one. In my odd little sense of humor, I call my plugin BAR-Tab, with the tag line "keeping tabs on your BAR files" :). The beauty of this solution is that the plugin can easily be deployed to the Message Broker Toolkit and be used in concert with the standard Broker Archive Editor. Here are screenshots of BAR-tab compared with the default tooling.






This is only version 0.9 of BAR-tab, therefore at this time it is read only and it doesn't have any pretty icons. Leave a comment or contact me if you want more details.