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.
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:
Here is a summary of the differences between the configuration storage modes:
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.
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:
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 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
Let our experts teach you how to use Sitefinity's best-in-class features to deliver compelling digital experiences.
Learn MoreSubscribe to get all the news, info and tutorials you need to build better business apps and sites