Version tracking and import trigger

Overview

When you export structures for deployment on the next environment, the changes are saved in folder ~\AppData\Sitefinity\Deployment. When the folder is uploaded to the next environment, Sitefinity CMS checks whether the contents of the folder have changed since the last upload. If there are changes, it triggers an import of the contents of the Deployment folder. To track whether there are changes, Sitefinity CMS uses a version.sf file that is associated with each folder or file. The same logic is applied to Add-ons, where Sitefinity checks the version of the .nuspec file of the add-on.

Version tracking

Sitefinity CMS stores the versions for each folder and files in a separate version.sf file. The file is used in both content and structure folders that are part of both Export for deployment and Add-ons – located in folders Deployment and Export, respectively. In the database there is a column in the Packages table that stores the version for each folder and file that are currently imported.

The version.sf file is generated on export and is automatically updated on each consecutive export and changes the version GUID.

NOTE: If you manually change any of the exported files, located in folders Deployment or Export, the “version.sf” files is not updated automatically. If you want to trigger import of the changes on the next environment, you must manually update the version GUID.

EXAMPLE: The following is sample content of a version.sf file:
{
"Version": "cdd18ebc-4d83-4b78-930c-6dcd8e92bbf9"
}

Import trigger

When the application starts, for each folder, Sitefinity CMS compares the version in the databse with the version in the version.sf file. If the version in the file is different, Sitefinity CMS triggers import of the folder. After the import, the version in the database is updated.
The .nuspec file version is used for add-ons. If you have updated an add-on, the version in the .nuspec file is incremented. In this case, Sitefinity CMS triggers import. For add-ons that have not been updated, import is not triggered.

Backward compatibility

In case there is no version.sf file, hash values will be used.
When a package goes through a continuous delivery process, this causes changes in the hashed values and triggers the import process, even if there are no changes in the content of the files or folders.

When the website initializes, if there is no version.sf file, it will fall back to hash value comparison. This might happen, if there is already exported data part of the source control or add-on that needs to be deployed. If the version.sf file is missing on the live environment, it cannot be created upon application initialization, because the next deployed package will override that change (each package is deployed on a clean folder).

RECOMMENDATION: We recommend that if you have used Export for deployment, you should do a new export after the Sitefinity CMS upgrade to 10.x or above. The version files will be generated during the first export.

Increase your Sitefinity skills by signing up for our free trainings. Get Sitefinity-certified at Progress Education Community to boost your credentials.

Get started with Integration Hub | Sitefinity Cloud | Sitefinity SaaS

This free lesson teaches administrators, marketers, and other business professionals how to use the Integration hub service to create automated workflows between Sitefinity and other business systems.

Web Security for Sitefinity Administrators

This free lesson teaches administrators the basics about protecting yor Sitefinity instance and its sites from external threats. Configure HTTPS, SSL, allow lists for trusted sites, and cookie security, among others.

Foundations of Sitefinity ASP.NET Core Development

The free on-demand video course teaches developers how to use Sitefinity .NET Core and leverage its decoupled architecture and new way of coding against the platform.

Was this article helpful?

Next article

Export a ZIP file