As well as the system installation concepts we have discussed in the last few articles I wanted to cover a couple of software features I put into most of the software I write to ease longer-term support and easy setup.
When I started writing software, I would often end up doing an install and then setting up the file system. Now I avoid that.
The software itself will create any directories it depends on and creates a sensible default configuration.
Creating directories can be done as part of the installer, but I tend to end up putting it in the software itself as it usually integrates well with other features.
With this setup, when you complete the installation, the software will just run.
I will include a version number with configuration formats and ensure that the software can at least take one previous version and migrate it to the new format. Conversion generally means handling:
Again, this is about ease of upgrading. The last thing you want to do is hand-tweak ten config files (and the likely typos and syntax errors that come with it!). If you need others to do an upgrade, this is also likely to generate many support calls.
Instead for a small investment in coding time, you can make that upgrade process seamless.
Did you remember to rename the DAQ card? Relying on hardware names is essentially another external dependency to remove.
Unless your software expected to sit on a very general-purpose system – I use the system configuration API to auto-detect all the hardware I can. For DAQmx, FPGA and VISA-USB you probably shouldn’t have to type a name in a configuration again.
I use the code example below on a system designed to support multiple FlexRIO cards:
By auto-detecting this we remove a step from every system setup and any debugging session looking at hardware.
That’s all the articles on configuration management for now. We’ve gone from why configuration management through to looking at platforms and now software configuration. The full list of items is below or get in touch if you have questions.