Visual Basic

Configuration Management: Just Do It!

Configuration management is one of those tedious details that are often not implemented or are poorly observed. The problems caused by the lack of good configuration management become apparent only when it's too late to do the job properly. A project manager must ensure that code versions are managed across all implementation environments. Yes, that does include the mainframe JCL, the SQL, and the documentation. The structure of the database, the versions of any DLLs, ActiveX servers, operating system and network components, and procedures should also be under configuration management. Does your source code control software make it easy to manage the configuration of the entire system? Has anyone figured out how to do it? Probably not, so you'll have some work ahead of you to work it out and get it right. Do it now!

A Visual Basic 6 distributed application can have many interacting pieces of software. Changes in the configuration of each piece can cause ripple effects into other components. Code effects can be managed by maintaining consistent interfaces. Changes in loads and performance characteristics might require changes in other components. New versions should always be extensively tested before implementation. The potential for changes being required or imposed in interfaces grows with the number of interacting components.

Dependencies among components might be disguised. (For example, the query "Select * from X" includes an implied column ordering.) Rolling out an application or a new version can be a nightmare. Configuration management controls need to be handed over at the end of development to those carrying out support. It makes sense to involve support staff early so that their requirements are included in the configuration management plan.

One of the biggest challenges in configuration management is to make the controls supportive to the developer. If they are not, creative talents will be turned toward breaking the system.