app_data/Sitefinity/Configuration - design change

Are there any plans in the future to tame the beast that is the configuration files stored under app_data/Sitefinity/Configuration?

It doesn't make sense to me why so much data is stored in these configs. To me, only environment-specific variables, like those found in DataConfig.config or SiteSync.config should be stored there. Everything else, such as Dynamic Modules or custom fields on existing modules is really content and content structure, and should be stored in the DB. In addition, this data should sync with the new site sync feature. 

Having to keep these files in sync between developers, dev ops teams and site sync is a massive burden!!
Also, given the current state of config management, why hasn't there been any documentation written on how to handle working with these configs between different teams and deployment environments? 

You do have the option to store the configuration in the database by adding a entry in your web config.

docs.sitefinity.com/administration-turn-on-database-storage-for-configuration-files

Note that at the point you start doing this the config files in your directory become the default and effectively static files. But you can't delete them. Adding the database storage doesn't transfer the values to the database storage.

The storage is simple enough. You will find a table with a row for each config file with the xml stored there.

I would like the ability to move it all to the database. (Though some will need to remain) but at this stage you can't. (You could manually transfer it I guess)

These days starting a new project I create the project and database and the first step is to then set the database storage and restart the site. You can not create a new project using database storage. You need to create the site and database first and then change it.

Hi Darren,

Thanks for the reply. However, I'm just not sure what problems moving the configs to db storage will solve in this case. If the configs don't get synced with site sync, and the environment specific configs, such as the connection strings or site sync info, are now coupled to the database, then I would think it would make things even more complicated when deploying to different environments :)

Yes, I do take your point. I move my connection string to the web config so I can manage its value through my deployment pipeline.

Though for me I am not sure what configs I would want to sync through. Currently I have the mindset of not syncing configs. I make the changes per environment. Though I do set a bunch of standard settings at the start and those get pushed through on the first release.

I think its a complicated one because what would work for one group may cause problems for another.

I don't disagree with you though. I have written blog posts and a book chapter talking about the config management short falls.