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.