Discussion
· Oct 8

What strategy do you use to maintain different settings of Interoperability Productions across DEV, TEST, and PROD environments?

#Deployment #Git #Interoperability #Management Portal #InterSystems IRIS #InterSystems IRIS for Health

I know the next ones:

1. Place all different settings in environment variables. You have a different .env file for each environment, and you must add some code to Production for reading and setting these values. It's good for deploying into containers, but challenging for management when we have a large production. I mean, we have many settings that can vary depending on the environment: active flag, pool size, timeouts, and so on. Not only endpoints.

2. My own case. A deployment script that saves Production settings before pulling from git the current state of Production, and restores the start settings after. In this way, each environment has those settings that were set in the Management Portal last time. The Production class is controlled by git (it keeps the default settings for added elements). Needs additional code for deployment as minus. And the content of Productions should be the same in all environments (like in the first solution, however).

3. Default Settings - official way to solve this problem, as I understand it. Not tried it, can say nothing... Is somebody using it? Does it work, useful?

4. Different production classes for each environment, I mean: TestProd.cls, DevProd.cls, etc. Not tried it yet, but it looks easy, no need for additional code, can be different content in Productions. Its obvious disadvantage: you must configure each item twice (or more times) for each Production.

What do you use? I skipped something? I would like to invite you to take part in the discussion.

What strategy do you use to maintain different settings of Interoperability Productions?
Results:
0%
(0 votes)
Environment variables
25%
(1 vote)
Saving-restoring production setting on deploy
50%
(2 votes)
Default Settings
25%
(1 vote)
Different productions
0%
(0 votes)
Other
All votes: 4.
Discussion (10)3
Log in or sign up to continue
Eduard Lebedyuk · Oct 8

Health Connect Cloud clients use System Default Settings. SDS serve two purposes:

  1. Providing environment-specific settings (i.e. Port).
  2. Providing settings common to several BHs using wildcards (i.e. Connect Timeout).

They can be easily integrated into CICD processes. Starting from 2024.1 SDS can also control enabled/disabled state of individual BHs.

2 0
Ben Spead · Oct 9

SDS has been supported since Caché, what are your version concerns?  

For the record, formal best practice across all InterSystems internal applications, as well as InterSystems-led implementations of HealthShare and TrakCare/Intellicare is to use SDS so that Production classes / code can be consistent across all all source code branches.

0 0
Andrew Sklyarov · Oct 8

That's what I was thinking when I described these options: 4, it's just not an automated version of 2. I would use copy and paste or some merging to add the same items across Productions. And automate merging of content while keeping individual settings - it's the obvious next step, right? 

Yes, it's a good solution if we want to keep a different structure of Productions (to keep development stuff on DEV Production). But I believe it's not a big problem, I'm just committing all new services in a disabled state (actually, they're disabled automatically). Therefore, stuff under development, yeah, can get to PROD but in an inactive state.

Just thinking out loud, so to speak...

0 0
Timo Lindenschmid · Oct 8

ISC supported customers should be looking into the use of ISC CCR (ChangeControlRecord) as well as SystemDefaultSettings. CCR is powered by Perforce and handles the transport of config and code between environments. It features in its latest version Production decomposition which transports only the actual changed code/config and no longer the complete production definition.

3 0