Multi-Environment Site Property
255
Views
7
Comments
New
Ideas

As a developer, I want to assign set 3 values to a single Site Property for all environments. This will dramatically speed up a deployment, where you won't browse several modules and change Site Properties depended on Environment.

It is common practice when we set a Site Property value to production value by default, and change it manually in Dev and Test. In this case we kind of avoid a "human error" if we forget it during deployment. But sometimes we have several such properties, e.g. SomeDomainUrl, which should be different for each environment.

I would suggest to inherit the practice we use in not low code:

we might have several configuration files for each environment, e.g.:

  • appsettings.json
  • appsettings.development.json
  • appsettings.test.json

That means during a deployment build process the compiler will choose corresponding settings.

How I see it:

When you add a new Site Property, you can add (+) two more for tst and prod. If a developer does not add it, they are the same by default. Like that:

Site Property: fromEmailAddress

  • Value: "noreply-dev@mydomain.com"
  • (+) tst Value: "noreply-tst@mydomain.com"
  • (+) prod Value: "noreply@mydomain.com"


What a nice idea! 

Hello Dmitrii,

Actually, what you suggest is already possible through LifeTime. 

When you're deploying your apps to the next environment, LifeTime detects the presence of new Site Properties and provides you with a field for each one for you to set the effective value each Site Property will have in the environment where the code will be deployed. This way, you don't need to go to the target environment's Service Center afterward to manually set the SP's effective value.

Ok, you can't set the effective value for all environments, but I think it's a nice accelerator.


Regards.

Hi @Ricardo Reis . You are right. But I want to control it at development time. Deployment might be done by different person who is not aware what settings are.

Ok, I understand your point, but I don't think your idea can be implemented in Service Studio. 

You see, each Service Studio instance is connected to one environment only, so how does it know how many and which are the other environments you have in your factory? Only LifeTime knows that.

@Ricardo Reis Liftime has API. Service Studio developers can easily fetch all environment names/data and create multi-SiteProperty at runtime. 

Awesome

I don't think this can be done in Service Studio, furthermore, infrastructures can have up to 12 environments, with each their own permissions set per LifeTime User.