Tue, 30 Aug 2005
Maintaining multiple installations of software
I have taken over a maintainance of a set of computers, which run an in-house developed software for chip card access terminals. The software runs on about a dozen computers all over Brno, and handles things like loading the database of valid cards, mapping valid users to the access terminals, and uploading log data to the central system. However, almost every installation has something special - some of them run a local card cache in a MySQL database, because they handle bigger number of cards than the hardware itself can store, one has a time-based constraint (the electronic door lock should be open during prime time, and closed with access with valid card only otherwise), etc. So the code base of the software is in fact not unified, with local specialities scattered all over the code base. Now the question is how to maintain this software, and how to roll out some bigger changes like a code refactoring.
The first idea about how to maintain those slightly different versions of software is to use a version control system (such as Subversion or GIT). However, this approach have some drawbacks: It does not in fact solve the problem of different versions of software, and any change in the "main" (or any other) tree should be merged to all other branches by hand, with a risc of forgetting to merge something and further code divergence. Another problem is that - when making a decision to change some code - it would be nice to know that "this area of the source code is the same on all installations", or that "this area is slightly different on that particular installation, so any changes should bear in ind this difference". In other words, this approach is error-prone and needs lots of manual work.
Another approach can consist of the refactoring of the code, and make the local specialities present on all installation, and switch them on or off in the configuration file. However, this would require lots of work, and it is not suitable for an incremental work - in that case I should restructure the code, and in one "big bang" install it everywhere. Not nice, and it brings a lot of stress in case something goes wrong.
The problem of its own is how to do a configuration of this software: on some machines there are several independent copies of this software, every one of them driving its own ring of card readers and door locks. Should I make them to use a common code directory and different config files only? And if so, how should I tell the program which config file to use? The system consists of several scripts, so I would have to be careful to pass the correct argument to all of them. At present every copy has its own directory with configuration and all scripts copied. Should I decide to use a version control system, how to structure the repository, so that both the software and the particular configuration file can be checked out on the destination host?
You can make a wild, uneducated suggestion in the comments section, but do not expect it to be meaningful, unless you have maintained a similar software with local differences. For now I think I will continue to make changes locally and an occasional manual backup - I need to make changes now, unfortunately. The main database of our system has been converted to use the UTF-8 internal encoding, and older Oracle clients (pre-9.2.0) stopped talking to the database, so I need to fix this up fast. Sigh.
If you can read Czech, see also my mail on this topic sent a while ago to the local Linux mailing list, and the resulting thread.