I'm currently testing the ability to add dynamic modules via the ModuleBuilder and synchronize them with to a staging server with SiteSync. The sync seems to work fine but I noticed it doesn't make any changes to the *.config files on the staging instance (sync target). Is this a problem? If not what are these files for and when should I deploy them?
More detail on what I'm doing:
On my dev instance I first create a module by going to Administration-->ModuleBuilder; then I create the module and give it a few fields. After doing this I notice that four configuration files are changed In project path\App_Data\Sitefinity\Configuration (ContentViewConfig.config, DyanmicModulesConfig.config, ToolboxesConfig.config, WorkflowConfig.config).
Next I sync them by going to Administration-->Staging & Syncing (on dev); from here I select to sync all changes to the staging server.
On the staging server I now have the new module & content types and I can add new modules fine.
When I diff the staging server it appears that no changes have been made to the *.config files however on the dev instance I can see changes to these that include the new content type. Do I need these new .config files on the staging server? It seems to work without them.
The Staging/Sync appeared to sync fine, and the content types appeared to be functional even though those files were not copied. Can you tell me specifically what those files do? Are they required? How come the module/content types appear to work without them? What is the side of effect of not having them on the target server?
What is the purpose of the dynamic module sync if the files are not pushed as well?
I'm trying to understand the sync better so we can use best practices.
Thanks Vassil. My question is more specific to the dynamic modules. In this case I had added a custom (dynamic) module with some content items.
After doing the site sync the second instance seemed to work without the updates to the DynamicModulesConfig. On the target server I could see the new content types and add them. Also I didn't not see any errors.
What would be the downside, or the effect of not having the updated config on the target server? It didn't appear that they were needed because after the sync everything seemed to work.
Part of my goal is to establish a best practice for development and deployment of new changes when a new dynamic module is required. How does this sound so far:
1. Add new module using module builder on staging server.
2. Add new content for dynamic content item on staging server.
3. Copy updated *.config files to all production servers.
4. Perform site sync of new dynamic content types (structure only) to production servers.
5. Perform site sync of new content items to production servers.
6. Restart production server instances.
In testing I only performed steps 1, 2, 4, 5 and the new content types & data appeared on the target servers with no issues or errors.
Are steps 3 & 6 required? And if so, why is it in my testing that it worked without it?
The list could be quite long and there is a reason to store such data in the config files.
There is a way to store your config files in your database (described here: link), but they are not synced. I believe in some of our future releases this could be possible, but for the moment it is not.
I hope this information helps.
The easiest way to understand and witness all above is to create a copy of your dynamic module config file, and add new module or some custom field. Than you can compare both files.
I wish Sitefinity provided better documentation on when config files are changed so we could better implement Site Sync.
I can't just be syncing my config files between staging and production. Obviously the connection strings are different and I wouldn't want to push new config files prior to actually running my Site Sync and pushing the DB changes.
The reality is that sometimes when you run Site Sync, you also need to sync up your config files. It seems like whenever you change structure instead of just content, those are the times config files need to be sync'd as well.
I also don't know what implications choosing to store configuration in the database has on this. I assume Site Sync doesn't sync the DB data that stores the config files, if you are storing config in the database. If that's the case, it's a lot harder to sync the config files (which are actually database tables).