Upgrades in Continuous delivery

Continuous delivery ensures smooth upgrades without manual work and with minimum downtime of your Live environment.

The following diagram demonstrates how to upgrade your project in Continuous delivery:

1. Upgrade the Development environment 
   1. Download and restore the database from your Live to your Development environment.
   2. Change the connection string to point to the restored database.
   3. Upgrade the Development project.
      For more information, see Upgrade.
2. Upgrade the Test environment 
   1. Download the project from the Test environment to the Development environment.
   2. Turn off Read-only mode of configurations.
   3. Upgrade the Test project
   4. Download and restore the database from your Live to your Test environment.
   5. Upload the upgrade project to the Test environment.
   6. Change the connection string to point to the restored database.
   7. Turn on Read-only mode of configurations.
   8. Run and test the upgraded project.
   9. If the tests fail, go back to your Development environment, fix the problem, and return to Step
3. Upgrade the Live environment 
   1. If tests pass, download the project from the Live environment.
   2. Turn off Read-only mode of configurations.
   3. Upgrade the Live project.
   4. Turn on Read-only mode of configurations.
   5. Upload the upgraded project from your Development environment to your Live environment.

RESULT: All of your environments are upgraded successfully.

When you upgrade your Sitefinity CMS project on your local development machine, you can easily transfer the upgraded .config files to the next environments from the continuous delivery process. You do not need to upgrade or merge the .config files manually. This is possible, because the versions of Sitefinity CMS and all application modules are no longer stored in the SystemConfig.config on the file system, but in the database.

The SystemConfig.config file stores the information about the modules state, but does not store their version or the error message data. These are stored in the database in a dedicated table – sfmodulevrsn.

Database table sfmodulevrsn transfers and stores the following:

• The global Sitefinity CMS version
  Sitefinity CMS versions 8.2 and below keep this information in SystemConfig.Build and SystemConfig.PreviousBuild.
• The static modules’s version and error message
  Sitefinity CMS versions 8.2 and below keep this information in SystemConfig.ApplicationModules for each static module.
  Table sfmodulevrsn stores modulename, version, previousversion, and err_msg.

Sitefinity CMS also uses a new UpgradeConfig.config file that keeps any data, which is deleted from other existing configurations, but is needed for the upgrade of the next environment in the continuous delivery process.

Process

The following happens when you upgrade your project on your local development machine:

1. On Sitefinity CMS initialization (SystemManager.Initialize()), additional logic checks whether sfmodulevrsn table is empty. 
   If the folder is empty:
2. SystemConfig.ApplicationModules are saved in UpgradeConfig.ApplicationModules.
3. Version and error message for each module in SystemConfig.ApplicationModules are removed.
4. Table sfmodulevrsn is initialized with the current modules state.

NOTE: Modules which are uninstalled on the initial (development) continuous delivery environment are deactivated on the next environments. No uninstall logic is executed. Because the error message for each module is stored in the database, if there is an error for a given module on one of the NLB nodes, the module is deactivated on all other nodes.