New CI/CD pipeline
The CI and CD pipelines have been rewritten to use YAML and unified under a single end-to-end pipeline. This allows for the automated generation of the YAML code based on the customer setup specifics, which improves setup automation and significantly reduces chances of incorrect pipeline configuration. Having CI and CD under the same pipelines allows for easier tracking of deployed changes across different releases. Some of the more significant improvements are listed below. More information on the new CI/CD pipeline can be found in the following article - https://www.progress.com/documentation/sitefinity-cms/cloud/code-deployment#promote-your-code-to-the-production-environment
The configuration management process across environments has been greatly simplified. There is no longer need to set app settings in the web.config file in order to transform them. Customers can now add custom app settings directly to the AppSettings variable groups. The CI/CD pipeline will set them as App Settings during deployment. You can read more in the following article - https://www.progress.com/documentation/sitefinity-cms/cloud/use-different-configurations-for-different-environments
NuGet package cache
The CI stage of the pipeline uses the built-in Azure DevOps Cache task to cache NuGet packages across builds. This reduces the time it takes to execute the CI stage, because NuGet packages are downloaded from the cache, instead of restored from scratch on each run. The cache key is based on the contents of all packages.config files. This way, the cache is not used in case packages change.
The MS build task part of the CI now builds and publishes the web project that is deployed, instead of the whole solution, which executes faster.
The deployment process intelligently checks for the exact file changes between the previously deployed commit and the current one. If you have made changes only to files that do not require application restart, such as for example JS, CSS, TXT files, the deployment process detects this and performs a partial deployment, which is much faster.
Automated notifications in case of failure
In case of failure, the pipeline will send an email to the customer stating the problem and proposing a solution for common issues - for example, the Sitefinity application failing to startup, which causes the warmup task to fail. In case of unexpected failures, the customer is notified that the Sitefinity Cloud team is looking into the issue, avoiding the need to open a support case.
New pipeline parameters
Parameter to enable/disable automated rollback
There is a new parameter that allows you to enable/disable the automated rollback mechanism for the "DB.RestoreBetweenEnvironments" pipeline, which rolls back the DB restore in case the target environment is unhealthy after it. This is useful if the target environment is unhealthy before the restore.
Parameter to enable/disable persistence of Sitefinity config values on DB restore
There is a new parameter that allows you to enable/disable the mechanism for persisting Sitefinity config values on DB restore for the "DB.RestoreBetweenEnvironments" pipeline. By default, the Sitefinity config values in the target DB will not be replaced with the one from the source DB.
- Azure Redis Cache service tier has been upgraded to offer better availability and lower network latency
- Sitefinity Management Portal "Welcome" page now has a "Metrics" link for each environment which leads to better and more detailed metrics Dashboard