New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Orchard environmental settings discussion #825

Closed
anoordende opened this Issue Jun 15, 2017 · 2 comments

Comments

Projects
None yet
3 participants
@anoordende
Copy link
Contributor

anoordende commented Jun 15, 2017

Gathering some thoughts on how Orchard2 deals with environmental settings in conjunction with a multi-environment release flow.

Background

We work with the notion "code flows up, content flows down", meaning that code changes flow from Development Environment -> Test Environment -> Production Environment, whereas CMS content flows in reverse Production Environment -> Test and Development Environments.

The reason for this is to be able to code and test against real-world data, of course with the relevant obfuscation of sensitive data stored in the db, including user account data.

In a Perfect World

All environment-related settings, assets and configuration are in App_Data (e.g. Settings.txt), Web.config or, more recently, appsettings.json. Only "portable", environment-agnostic content is stored in "the database".

This means that no data transformations are required to restore from Production to Test or Development.

In the Real World

Environment-related settings do find their way into the db, especially where settings relate to hosts. In Orchard1 a good example is the SecureSocketsLayer module (Secure Host and Insecure Host) and site settings such as UseCdn. In Orchard2 a good example is the OpenId module (Authority, App Redirect URL's, etc.).

This means that flowing the CMS content from Production to downlevel environments is somewhat more complex as these settings need to be updated to match each environment.

Discussion Points

  1. Is this an issue worth discussion and, if so:
  2. Is Settings.txt being under-utilised in favour of db-stored settings?
  3. Should the guideline be to not store any environment-related settings in the db?
  4. What would be the definition of an environment-related setting?
  5. Is there an overall better solution to this problem?
@Jetski5822

This comment has been minimized.

Copy link
Member

Jetski5822 commented Jun 15, 2017

I just a PR #826

What this will allow you to do is register your own... IShellSettingsConfigurationProvider at the application services level.

This allows you to pull in configuration values from anywhere and get them pushed to the Dictionary in ShellSettings, including environmental configuration. maybe this could help

@jtkech

This comment has been minimized.

Copy link
Member

jtkech commented Dec 8, 2018

Just for infos and as a reminder, in the distributed branch i needed to fix some race conditions in our YamlConfigurationProvider when syncing tenant settings.

And looking at this aspnet pr saying Remove the ability to commit configurations, we will have to find a solution to save / sync settings.

I will start working on Provide a per-tenant configuration story #2038, e.g to take into account the current environment.

sebastienros added a commit that referenced this issue Dec 8, 2018

Adding configuration support
Fixes #2038
Fixes #1456
Fixes #825
Fixes #2051

@jtkech jtkech closed this in #2824 Jan 25, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment