This blog is about the latest capabilities allowing adopters to edit configurations directly in Sitefinity Cloud environments, or our quest for the holy grail of Sitefinity configuration management and answering customer needs in line with the best CI/CD practices.
I Am a Sitefinity Admin Too, and I Lived to Tell the Story
In the beginning, everything used to be quite straightforward. Sitefinity configurations were stored in the file system. You could make changes, transform them when publishing your website to a server somewhere and store them in a source code repo. Ah… simpler times. What could go wrong?
As time went on though, many of us had to start dealing with more and more pressing questions. How are we going to deal with runtime configuration changes that differ from the source code? How are we going to keep configurations consistent across multiple environments? How are we going to recover the application in case something goes wrong, and we lose the files that were changed directly on the server? Ugh…
And then, after a while, there seemed to be an answer to some of those questions. Enter DB mode. So, you could make runtime changes from the Advanced Settings screen on any environment without worrying that those would conflict with the files in the source code. You could also easily restore your application using a DB backup.
But then again…
How do you ensure consistency if you need to go and make changes by hand in each environment? How do you obfuscate secrets when you create a DB backup that needs to be used by a developer, so they don’t gain access to Production services? How do you restore the Database from one environment to another without overriding the environment specific settings on the target? Ugh…
We had to wrestle with these same questions because neither FileSystem nor Database modes were complete solutions. So how did we solve this problem back in the day?
With Auto-storage mode, we combined the power of FileSystem and Database modes:
- Environment configurations that are part of the system setup are stored in the file system. They are part of the deployment process of the web application, and you distribute them as files between different environments. Such configurations are the Advanced settings of Sitefinity CMS.
- Application settings that are part of the Sitefinity CMS website and are modified runtime are stored in the database.
Here is a summary of the differences between the configuration storage modes:
And Then We Had to Take it All to the Cloud
Then Sitefinity Cloud came along, and we had to deal with all that complexity drink our own champagne. We wanted to be in line with CI/CD best practices, so we combined Auto mode with Read-only file system mode.
This meant that all configuration files are in read-only file system mode on Sitefinity Cloud environments, which streamlines file system configuration changes to happen through the source code making them easily trackable, mergeable and comparable.
By disabling the ability to save configuration changes on the file system, the source code becomes the single source of truth regarding the application files. The application can then be easily recovered by restoring a DB backup and re-deploying the latest deployment package. The read-only file system mode also protects the application on the Production environment from accidental changes that could lead to downtime due to unwanted restarts or configurations.
While this is all great, it doesn’t solve all customer needs. There are configuration changes that users want to make at runtime, without having to set up the project locally, commit the changes and wait for the CI/CD pipeline to run.
Ok, bear with me here… the Auto config mode provided the ability to have configuration files both on the file system and DB and merge them at runtime. To make configuration files editable and store the changes in the DB however, developers had to write custom code that uses the necessary APIs under the hood. Easily editing configuration files through the Administration Settings screen and saving them to the DB was not available.
Sitefinity Admins, We’ve Got News for You
As announced in the release notes, to facilitate the need for easily making runtime configuration changes through the Advanced Settings screen, Sitefinity Cloud customers that have upgraded to Sitefinity 14.3.8022 (or higher) can now take advantage of the enhanced configuration editing capabilities, which allow specifying which configuration files, sections or properties should be fully editable directly on Sitefinity Cloud environments.
With this change we believe that we now have a complete solution that covers all bases:
- For configuration changes that do not vary from one environment to another and do not contain any secrets, you can update configuration files on your local development environment and push the changes to the source code.
- For configuration changes that need to vary from one environment to another and do not contain any secrets, you can use configuration transformation files that will be applied during deployment to different environments.
- For configuration values that must be secret, you can use Azure DevOps variable groups to configure App Settings and Connection Strings for the application. This is a neat little feature, because it allows you to override specific config values and make them immutable for runtime changes.
- In addition, anyone browsing the application would not be able to see the actual value, so these are ideal for API secrets, keys, etc. Furthermore, if you export the Database from any environment and restore it locally, the secret values will not be there. These values are applied during deployment via App Settings and Connection Strings in the App Service hosting the application, so they are persisted directly in Azure, not on the file system and not in the Database.
- For runtime configuration changes that do not contain any secrets you can now make them directly on Sitefinity Cloud environments.
- If you restore the Database from one environment to another (DB.RestoreBetweenEnvironments pipeline) or import a Database (DB.Import pipeline), the default option is to persist Sitefinity config values on the target environment. This means that Sitefinity config values stored on the target Database will NOT be replaced with the ones from the source Database. If you want to override the configurations on the target environment, you can disable this option when you run the pipeline.
NOTE: These different approaches to managing configurations are not mutually exclusive and can be combined. For example, you might have a configuration section available for runtime configuration changes on Sitefinity Cloud environments, while at the same time override a specific configuration value from that section, because it is an API key that should not be visible and editable.
For more details, please visit the manage configurations documentation. Want to learn more about Sitefinity Cloud?
Yasen Yankov
Yasen Yankov currently leads one of the Sitefinity engineering teams. Prior to that, he spent 5 years developing and maintaining Sitefinity applications as part of the Progress web team. He has worked on complex web projects like telerik.com, progress.com, sitefinity.com and nativescript.org