Single- and multi-user development environments and source control

Question

Question

Michael Derr · 1 hr ago

#Containerization #Continuous Delivery #Continuous Integration #Embedded Git #Git #Source Control #VSCode #InterSystems IRIS #InterSystems IRIS for Health

We are a group of interface analysts in a healthcare setting, running IRIS for Health 2024, having upgraded over time from an old ENSEMBLE environment. We have been working on a wish list of development goals, but are having trouble finding the correct, best practice method/path for getting to what we envision.

Current state: We run IRIS for Health on a Redhat 8 virtual machine. We run Interoperability productions (IE.cls) out of 6 namespaces. We have a dev/test box and a production box. This is a multi-user dev environment by default: Studio (and later VSCode) and the GUI dev tools (DFT Editor, etc.) were the default dev tools, so each analyst edits code on the dev box. Edits are captured by embedded-git and sent to namespace-specific repositories in Azure.

Issues: The main issues we'd like to address now are source control. Currently, only one branch can be worked on in each namespace, which means we cannot easily have multiple developers working on different branches/projects within one namespace.

Is multi-user development the norm with IRIS? Does it make sense for us to have source control at the local level, where each dev could make their own branches for specific projects, and only send them to the dev server then? Would we have both local and server source control then? How would local development work if the dev wanted to use one of the UI tools (like DFT Editor)? I've seen demos of devs using local IRIS containers, but I guess I just don't understand how our situation would work with these tools, especially cross-platform.

Apologies if I seem lost, but I really don't know how other places with multiple namespace productions are handling multi-user development with source control.

Product version: IRIS 2024.1

Discussion (2)3

Log in or sign up to continue

score 0 · Answer 1 · 2025-12-04T14:10:32-05:00

The far-future state we'd like to achieve is more of a master source control state with Dev>Test>Prod environments where changes we make in the development environment would be promoted to Test for testing and subsequently to production, but right now the differences between our dev and prod Interop Productions are such that we need to completely rethink them before we can possibly address the idea of whether some sort of environment variables can be established/used to customize production elements (such as service/operation names, ports, etc.)

score 0 · Answer 2 · 2025-12-04T14:34:50-05:00

Hi @Michael Derr, I recommend you have an isolated dev environment for each branch, whether that be a whole server or just a namespace. You can have Embedded Git configured to a different branch in each environment. Developers would then work in the environment that corresponds to the branch. This can be achieved with only server-side source control, but it also sets you up nicely to move to local source control in the future if that's a goal.