Best practices: SiteSync and Export / Import

The primary purpose of the SiteSync module is to facilitate promoting content between your Sitefinity CMS website environments. The Export / Import functionality, on the other hand, is designed to primarily facilitate the promotion of website configurations and data structure.

Therefore, it is best to use Export for deployment for promoting any Sitefinity CMS configuration or data structure changes. Leveraging Export for deployment facilitates best practices like source control and continuous deployment and provides full support for any configuration and database structure changes. SiteSync can complement this setup and facilitate promoting your content between the environments.

While SiteSync also supports promoting website configurations and data structure (data structure is limited only to Dynamic modules), if you are following best practices for website development you would rarely use this functionality due to the following aspects:

• Development usually happens locally
  When you are developing a new Sitefinity CMS module you rarely have your dev team do it on Staging or Content authoring. Developers usually work on their local machines, where the new modules, websites, or changes to the site configuration happen, and then these changes are checked in source control and deployed to the respective environments.
  Let’s take the following example:  you need to add a new module to your Sitefinity CMS website, which will facilitate marketing promotions. Your dev team members can start collaborating on adding a new Dynamic module, defining the structure, coming up with custom widgets and styles, and so on. To facilitate this collaboration, everyone is doing their part on their local machines, and checking in the changes in source control. However, some of these changes will be persisted in the database (for example, the dynamic module structure, or some specific configuration changes, if you are using configuration storage modes Auto or Database). The person who creates the module uses ImpExp to check in the changes to source control. All other people involved can now get the version form SourceControl and Sitefinity CMS will add the module to their local project. This process covers adding the fields, changing structure, and so on, until final the final version ends up in Source Control.
  Once development has completed, all the changes can be tracked, and can be deployed to the Staging and Live environments.
  At this point you can begin content editing and promote the content via SiteSync to the respective environments, where the configurations and data structure has already been taken care of.  
• SiteSync only takes care of Dynamic module fields and structure
  If you change a static module (for example, add a new custom field for News), you will not be able to promote this change via SiteSync. You can manually apply this change on live, but this would be against best practices. Therefore, you must use the Export for deployment functionality to have these changes applied to the other environments before you can use SiteSync to promote the content.
• No source control when promoting configurations via SiteSync
  If you decide on using SiteSync to promote configuration changes, none of these changes can be tracked or reverted, as they are not part of your source control. Following best practices, you must use source control and deployment instead.
• Incompatible with Continuous Delivery process due to overwriting values on destination
  If you have adopted a Continuous Delivery process, you can leverage config transformations as a mechanism for deploying environment-specific configuration values. Using SiteSync to promote configurations is not applicable with this process, as SiteSync overwrites the configurations with the values form the source environment.
  Additionally, if you are using configuration storage mode Auto (default option), Sitefinity CMS stores certain configurations in the database and others on the file system. If you use SiteSync to promote configurations, SiteSync will read the configuration from the source environment, combine the values stored in database and filesystem, and then write it in one location on the destination environment. This can cause issues if you decide to adopt a Continuous Delivery process at a later point in time, as you will end up having the same configuration value stored in different locations on source end destination, and you will not be able to apply config transformations. In such case your only option would be to restore the configurations and database from the source environment to destination, before you can leverage config transformations, which might result in losing some live site data like comments, forum posts, and so on.

For more information about enabling advanced SiteSync options like synchronization of configuration files, see SiteSync advanced settings.