Monday, April 26, 2010

Last year, I made a bunch of changes to automatically do a lot of the manual configuration that was involved in adding a new component and also managed to package everything to do with a component into a single jar file that gets its own ClassLoader so that different components can't interfere with each other. Two major things were making the SNMP configuration almost completely automatic, and automatically adding new database rows required for new components as needed. I did all this after two people involved in implementing the service left so I didn't have to worry too much about stepping on toes or having a bunch of bureaucratic meetings.

It has worked pretty well so far. The biggest snag was that some people ran a build that automatically added some rows to the database, then moved back to an older build that would refuse to initialize because database didn't match the configured components. This is no longer be an issue, as there aren't even builds that old in production.

However, there is another associated service that has a horrible tiered maven build that requires a bunch of configuration in two of the maven components as well as requiring new database rows be added for each new component. As long as somebody else is taking care of all of that, I don't care. But I've been called on to add the configuration when there are new components, and it's annoying to have to add almost 200 lines of boilerplate XML and request a minor database script update for each new component, and then go through the convoluted maven build process.

There are a few other associated services that, as yet, require manually adding stuff for each new component, but other people have been taking care of it. One of them is a hack onto a legacy infrastructure and is the source of most of the usage. Another two really ought to fetch everything associated with a component from the main service, which does have all the mechanisms required for doing so, but were implemented to have hard-coded copies of a few things for each component. But, for at least one of them, it's in the pipeline to do it right, after which it would no longer need any changes every time a new component is added.

The mentality that all new components need a database script update seems to be somewhat ingrained. Even today, someone asked me if they needed to run a database script, presumably for their development environment, as new components are being released to production in a few weeks. Their database probably already has had all the new rows for months, since the code for the new components have been in place for months.

No comments:

Post a Comment