I have been having a debate with my co-worker about the best way to manage config files for multiple environments (mainly production vs. development) and was looking for some outside opinions since he is mainly a web developer and I am a less experienced programmer. The overall problem as stated is this:
We have several small, in-house Qt applications with hardcoded configuration variables (database credentials, file paths, etc.) that I am planning to extract to XML files that the applications will read. Apart from it generally just being good practice not to hardcode these things, I would like to make for easy switching between development/testing and production settings, or any other environment we may need in the future.
My co-worker's thought: A separate dummy config file for each environment (e.g., config.xml.production, config.xml.dev) and it is up to the developer to change the name of the file they want to config.xml, which is the file that the application looks for. I don't like this because I think it invites more user error and I don't want to have to deal with renaming files all the time.
My thought: Either have one config.xml file with different nodes for different environments or a different config file for each environment, and then have a global variable in the application that decides which node/file to use (to be set by the developer as needed). My co-worker doesn't like this because he thinks that if we want to add more different environments it will be a hassle and that the config file selection shouldn't be within the application itself.
I can see both sides of the argument, what I'm wondering is: Is there a best practice on this for Qt applications in particular? Are we both totally way off base in our approach and why? I'm open to any and all thoughts. There is far more collective experience on this forum than there is between my co-worker and myself.
Bookmarks