Version tracking and import trigger
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.
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
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
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.
.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.
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.