Do you find it time consuming to keep track of customized scripts and configuration files dispersed among different NETeXPERT systems? When performing a system upgrade, is it difficult to keep track of the files that have been modified or created in your development environment? Have you run into issues where someone has made a modification to a script, without your knowledge, and you end up spending far too much time trying to track down what was changed? Do you find it hard to locate in your documentation the files that have been modified on your production system?

These are all issues I have run into while working on projects for a variety of customers. My experience has included working with small project teams as well as much larger ones. I have found that some people may or may not follow existing procedures that have been established for tracking modifications to the systems being worked on.

An example of one of the procedures I’ve worked with included:

System Log Book

The system log book is stored in a specified directory on each of the servers. The log book is actually broken down into separate text files by classification.

For example, a customer could have one for each of the following: OS Configuration, OS Patches, Database, NX Rules, NX Patches, and Custom Scripts.

Anytime a modification is made to the system, the Log Book for that modification is updated and includes the Date, Description of Change, What it effects, How to Rollback.

This procedure is great as long as everyone participates! Anyone on the team can go and look to see what has been modified or added to the system at anytime. However, what I have seen is that maybe 10 % of the time people are working hard with tight deadlines and often forget this important step in the process.

Some of the typical files that need to be managed include:

• Environment Files (.cshrc, .login etc)
• .netexpertrc
• NETeXPERT .lax files
• Backup Scripts
• Reporting Scripts
• System Startup / Shutdown Scripts from /etc/init.d, /etc/rc0.d, /etc/rc1.d, etc)
• Customized scripts that get called by NETeXPERT. Perhaps a dialog that executes a script in the shell.
• Operating System Configuration Files
• Oracle Configuration Files

The number of managed files to keep track of between a development system, test system and production systems can be quite large.

With my work at Longview Software, I’ve been able to spend some time working with our Version Control and Distribution (VCDS) product. I’ve found that having a GUI sitting on top of CVS to manage modifications to NETeXPERT Rules, Dialogs and Rule methods is extremely helpful. I can easily view differences between the systems, view history of changes and even deploy the latest version to a system with the click of a button.

Wouldn’t it be nice if this type of functionality were available for customized scripts and flat files in VCDS?

I’m positive this could have saved me countless hours fixing issues, deploying scripts out to various systems and just keeping track of modifications.

Add Comments