Tue, 20 Sep 2005
Maintaining multiple installations of software - II.
A while ago I wrote about problems with maintainance of multiple independent installations of software with local modifications on some installations. Now I can offer a few practical tips based on my experience with solving this problem (some of them are Perl-related):
- Put the config file name to the command line.
- The original software had the configuration file location hard-coded in the program itself. This means that even when you want to run multiple copies of the software on the same machine, you have to copy the whole program tree, which is a maintainance nightmare.
- Use the FindBin module.
- This module can save you from both hard-coding the module path into your scripts or requiring your scripts to be run from one directory only. This can help especially when the programs are started from various places (such as /etc/inittab), where setting the work directory or PERL5LIB environment variable is not feasible.
- Make reasonable defaults.
- You don't have to repeat all the configuration variables over and over again in each config file. When the defaults are sane enough, only the truly site-specific settings can be set in the config file. The config file is shorter and more readable then.
- Write your config file in Perl.
- When you do this, you don't need to write a special config file parser. And you can even write local hacks, which are specific to one installation only, into the config file itself as anonymous subroutines.
- Use Subversion.
- Especially when refactoring an old code lots of filesystem-related changes (file renaming, directory shuffling, etc.) are made. SVN is excellent for the filesystem-related operations, and provides a full file history including any renames. SVN is more mature than other version control systems, and when fully decentralized operation is not required, it simply rocks. There is only one shortcoming of SVN - you cannot "svn move" a file with uncommited local changes. But this can be worked around using an intermediate commit. Say sayonnara to the hell which is the Attic/ directory with the deleted files in CVS.
- Use different subtrees for different scopes.
- When you have everything in one directory (or subtree), the local hacks or even simple version control are nearly impossible. Use one subtree for things that are shared from everywhere, one subdirectory for local dynamic data, which are not under the version control system (log files, local state data, etc.), and one subdirectory for the site-specific data. I thougt about one more directory for install-specific data (when running multiple copies of software on the same host), but I have found that the separate config file for each copy (with all configs in the site-specific directory) is enough for my purposes.
So on this side things are going well, and I hope I manage to upgrade all my installations to the refactorized version of the software soon. Hope you find these general guidelines useful :-)