Does anyone have a suggestion for component configuration naming conventions?

pparlow's picture
pparlow asked on April 19, 2012 - 9:49pm | Replies (2).

I have a build that outputs various configuration files, some which are very similar but differ based on the attributes of the component they support. Our current naming convention for the configuration files consist of identifying the attributes supported:

Config_Foo_attr1.xml, Config_Foo_attr1_attr2.xml

As our attribute options grow so will the file names. Has anyone else dealt with something similar to this issue?

I'm trying to find an alternative to the option being proposed by those outside of CM. They would like the configuration files to be generated on the fly by a tool based on an operator's input during the download of the component.

Thanks,
pparlow

2 Answers

bglangston's picture

If there is "an operator's input during the download of the component[," then how will they know what the input was? How will they know what the last download actually looked like?

If the operator gets hit by a truck, who will know how to recreate the latest and greatest? What happens if the operator becomes disgruntled and decides to cause some damage by inputting malevolent code? (Had an argument with the boss, or was laid off/fired, or bad-hair day, or wife left him, or any other such thing)

Back to file names:
You don't mention what app (tool) you are using as a repository. However, most, if not all, have a provision for labelling files. That is the location I would use to identify the attributes. That is also where the folks would identify the change authorization - the one that said he/she could add an attribute. It's called change tracking.

Of course that results in more work, but that's part of the job, your's and their's.

So, you would have Config_foo_iter(ation)1.xml (labelled with) "attr1, authorized by Change Authorization (CA) 1 (or maybe JSmith email 20120425_1215pm)
Config_foo_iter2.xml: based on iter1 plus attr2 and attr3. Authorized by CA 2
Config_foo_ Etc.

That way, for each file, you know the attributes covered and who authorized incorporation of the new attributes.

The folks won't like it because it is a bit of extra work, but to do it the way they want will create chaos and you will lose application integrity before a lot of time passes.

pparlow's picture
pparlow replied on April 26, 2012 - 6:16pm.

First, let me thank you for replying.
Second, I've come up with a naming convention that has been accepted by our group and will limit the file name size.

We are using AccuRev as a source respository. Every modification to the configuration files are tied to either functionality changes or defect fixes. Every modification does go through an approval process before they are submitted to the CM for inclusion in our build.

I guess I really had two problems in the previous post. 1. The file name length, and 2. The resistance from developers to maintain individual Config files.

The operator downloading the components are unaware of what configuration files to select. They only need to input a configuration number. At this time our configuration options are limited so the list to choose from is small (the list of configuration will grow over time). As stated before we are naming the configuration files by the component attributes they support. I realized the configuration numbers defined exactly what attributes are desired so why not use the configuration number in the name of the file? So a configuration file will be named after the first configuration number it supports (i.e. Config_Foo_100.xml). Other configuration numbers may use the existing configuration file. This way the name will stay reasonably short.

The second problem is the number of configuration files which are 90% the same. In CM we are advocating for one configuration file with the 90% same data and individual configuration files for the unique data AND all checked into our respository. The developers would like to auto generate the configuration files on the fly during the actual download.

In my original post I was looking for suggestions concerning the first problem. The second problem will continue to be discussed.

Thanks again,
pparlow

CMCrossroads is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.