ModuleBuilder and SiteSync and config files.

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.

Hello Gary,

Actually SiteSync does not sync configuration files, so you need to do this manually. Here is how it is defined in our online documentation:
Except for the connection string and the SiteSyncConfig.config file, the configuration of the sites you want to sync must be the same (the content of all .config files in folder ~\App_Data\Sitefinity\Configuration\.) These does not include your web.config file.

You could use some third party tool for synchronizing files which you may use to help you automate the process, but for the moment this are the options we may offer.

I hope this information helps.

Regards,
Vassil Vassilev
Telerik

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 much.

Hello Gary,

In general config files store all custom data you have in other words any customization you do is stored in your config files. Of course they also store static data. Wen you perform some of the following is written there:

• Add a widget in your toolbox (stored in your ToolboxesConfig)
• Add a different user role (stored in your SecurityConfig)
• Add custom fields, custom modules (in DynamicModulesConfig)
• If you add /modify some data in Administration > Settings > Advanced (stored in different configs, depending on the data)

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.

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?

Thanks much,

Gary

Hello Gary,

Regarding the dynamic modules you could have the following scenarios:

• adding new items on already synced configs does not need new config syncing. For example: you create brand new dynamic module, add some custom fields etc, than you sync the config. After you create some items of this module, perform the sitesync and your items will appear on your production environment without syncing the configs as there is no need to do that.
• create a brand new module, but you do not sync the config - this way it will not work.
• create a brand new module, you sync the config, but after you add some more custom fields to this module - again, it will not work properly as the dynamicmodule config will not be "aware" of the new custom fields data created on your staging environment

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).