What strategy do you use to maintain different settings of Interoperability Productions across DEV, TEST, and PROD environments?
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.
Comments
Health Connect Cloud clients use System Default Settings. SDS serve two purposes:
- Providing environment-specific settings (i.e. Port).
- 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.
I'm glad to hear that the platform solution works well. I should try it too. But need the actual version of IRIS, becouse to control what is active across environments - it's very important, I believe
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.
SDS for "enabled" and "pool size" were made available starting with 2024.1.
Got it, thanks for clarifying
Thanks! It's interesting. Keeping different pool sizes may be more important to me than an active flag. Because I have many Business Operations with pool sizes like 100 or more, and on the DEV environment just not enough memory for it.
I use different productions because not all clients are on IRIS 2024.1+ and it's an easy way to not expose to live deployment stuff that's still under development. I believe Default Settings are a better alternative, to avoid code duplication.
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...
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.
There's also Deltanji from George James Software, the pioneers of the production decomposition technique.