Set environment agnostic Settings in Config.xlsx (REFramework)

Feedback Robot
, ,
1

Hello there,

One question about the Config.xlsx file (Settings sheet) from the REFramework: How do you set environment agnostic values in it? For instance, in the “Settings” sheet I would like to put some values particular to the dev environment and others particular to the prod (let’s say that one url is https://somesystem-dev.com/ and another one https://somsystem-prod.com/)

Thanks a lot!

Andoni

3

Hi @aaguirrearanguren

You add only one line for URL and then change it when deploying to another environment. The same way for others environment specfic configurations

You also can use Assets sheet for this. Below some differences

  1. Flexibility and Accessibility:
  • Settings Sheet: Environment-specific settings can be easily changed in the Excel file by the user or administrator without needing access to the Orchestrator. This is especially useful for quick changes or in scenarios where access to Orchestrator is restricted or managed by a different team.
  • Assets Sheet: Changing asset values requires access to the Orchestrator, and in many organizations, this access is limited due to security and governance policies.
  1. Environment-Specific Configurations:
  • Settings Sheet: It’s often more practical to store environment-specific configurations (like file paths, URLs for test and production environments) in the Settings sheet. This way, switching environments can be as simple as changing a few entries in the Excel file.
  • Assets Sheet: Orchestrator assets are more suited for values that need to be secured or shared across multiple processes, rather than for storing environment-specific configurations.
  1. Ease of Management and Version Control:
  • Settings Sheet: Excel files can be easily version-controlled using tools like Git, allowing for tracking changes over time. This is useful for maintaining a history of configuration changes.
  • Assets Sheet: While Orchestrator provides a secure and centralized way to manage assets, it doesn’t offer the same level of version control and change tracking as file-based configurations.
  1. Operational Efficiency:
  • Settings Sheet: Quick modifications and deployments are possible without the overhead of logging into the Orchestrator and modifying assets.
  • Assets Sheet: More suitable for values that don’t change often or need centralized control and auditing.

if you prefer use Settings sheet, it recommend to move the sheet to a shared drive to make easy change the configuration as needed when you are deploying the automation to other environment, this way you can change it without need to republish the code

Cheers

4

Hello @rikulsilva ,

Amazing answer, as always!

My idea is not to have tons of assets stored in Orchestrator (I do not see very practical having tons of process specific assets in Orchestrator). However I would also like to avoid manual work (like changing the entries manually when about to switch to a new environment).

My idea is to use some kind of xml/json with “dev” and “prod” sections, each populated with its own values. Then I could use a global asset per Tenant (for example) named “environment”, which would hold the value “dev” or “prod”, depending on the environment. That way when the process is moved between environments (Tenants in this particular example) whenever it’s deployed it would automatically pick “dev” or “prod” key specific Settings. What do you think about this? I see it a bit cumbersome to make developers or someone regularly change these in the Config.xlsx file before promoting it to another environment (humans can forget things hehe)

5

Thanks, @aaguirrearanguren

I think it is possible and it will work fine but it depends the company policies, governances etc

For example, in my current company no developers have permission in production tenant to add, change or remove assets. Only process controller or sustain team has access to avoid someone changes something critical or sensitive.

Critical assets like credentials or sensitve data are add to production tenant by Process Owner. CoE team doesn’t have access to them to prevent the credentials or sensitive data are used out side of automation environment

So, you doing some structured to capture information from config (.xlsx or .json) for both enviroment, for example, you might lose some governance and security aspects and maybe increases the effort to maintance them if some change happens in the future (if we need to change the URL or other environment aspect, in the scenario where you have all these environment details in the config file (.xlsx or .json), you would need to update all the configs files to reflect this change)

We are using Assets to manage common environment configurations across processes, such as URLs. We just create the asset and share it with the other processes that use it. So if we need change them, we just update the shared asset and this change reflect to all processes.

It ultimately becomes a decision of weighing the pros and cons considering the aspects and policies of the organization

Cheers

1 Like
6

Some possible options you could try:
a) Use multiple configs, one for each environment, and create an input argument to the process to control which config should be used in the run.
b) Create new sheets in one config, to keep environment specific settings.
c) Use suffixes to name the environment specific settings.

1 Like
7

Hi @rikulsilva ,

Definitely, that’s it!

I am still not used to the Folders in Orchestrator but I guess that you create Assets per folder and only share those that are a must to be shared, hence asset management is not that “chaotic” as I’ve imagined at first, as you have them segregated by folders.

1 Like
8

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.