Best practice for promoting environment-specific system properties?

[choff]

Hi all,

I am working in an environment with three instances, dev, test, and prod. As part of an update set I am developing, I am storing two dev-specific values as system properties (API URL and API Key). These values will need to be changed when promoted to test, and changed again when promoted to prod. In the past I have handled situations like these by manually editing the values during promotion via release notes. I am looking to see if there are official recommendations for ways to handle this that do not rely on manual processes.

[Mark Roethof]

Hi there,

Several ways possible.

You could create XML files for example, which on the higher environments can be imported. Or if you do this in Update Sets, you could update the customer xml.

Question1:
On the system properties, did you also add private=true? This will prevent that updates on such system properties, are accidently captured in update sets, and with that accidently promoted to higher environments (which can be an issue, since its instance specific you are mentioning)

Question2:

When performing a system clone, how are you ensuring these system properties are maintained? Have you setup Clone Definitions for example?

Kind regards,
Mark

[Amit Gujarathi]

HI @choff ,
I trust you are doing great

you can follow the recommended approach outlined below.

1. Create dedicated configuration records:

   • Create a new table in ServiceNow to store the configuration values, such as "Dev Configuration," "Test Configuration," and "Prod Configuration."
   • Add fields to the table to store the API URL and API Key values.

2. Modify your update set development process:

   • When working in the dev instance, update and use the dev-specific configuration record to store the API URL and API Key.
   • Instead of directly referencing the system properties in your code, retrieve the values from the dev configuration record using ServiceNow APIs or scripting.

3. Incorporate the configuration records during the promotion process:

   • As part of the release process from dev to test, include the test-specific configuration record in the update set.
   • Similarly, include the prod-specific configuration record when promoting to the production instance.

4. Update the configuration values in each instance:

   • Upon importing the update set in the test instance, update the API URL and API Key values in the test-specific configuration record to match the appropriate values for the test environment.
   • Repeat this process when promoting to the production instance, updating the values in the prod-specific configuration record.

[choff]

Thank you Amit. Your point 1 ended up inspiring a solution for me. I discovered that I can store all of the API URL and API Key values as properties (api_url_dev, api_url_test and so on), read the "instance_name" system property which is unique to each environment, and then use that to pull the correct properties based on that value. I haven't written the code yet or I would share it here.