Question
· Dec 4

Single- and multi-user development environments and source control

#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 (9)2
Log in or sign up to continue
Michael Derr · Dec 4

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.)

0 0
Brett Saviano · Dec 4

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. 

0 0
Michael Derr · Dec 5

Thanks for the reply.  I guess in my mind, a branch would be made each time a dev wanted to work on a new feature/project.  If we needed to set up a new environment each time we did that, we might be overwhelmed.  Perhaps some more details on our namespace setup would be helpful.

We have one namespace for handling most ADT/order/result HL7 messages, flowing back and forth to Epic.  We have another namespace that handles most of our sftp traffic between other systems like Infor and various vendors.  We have one namespace with an HL7 production dedicated to very high HL7 traffic from bedside monitors.  Then we have two namespaces dedicated to other ERP traffic and some outside charge/financial traffic (X12, SFTP again).  Each of these six namespaces has its own git repo on the server, managed by embedded-git, connected to Azure.  Presently each namespace has but a single git branch, which is shared by all devs.  If I, for instance, am working on settings in IE.cls for a new service, I make my edits and have locked the IE.cls from anyone else editing it until I commit my changes.

I think in my ideal world, I would be able to make my own branch for my modifications, make changes, then commit them to the server when ready (thus deleting the branch).  But if I want to be able to do that, I think we need to aim for a single-user environment, which means some sort of IRIS instance on my machine, or a dedicated environment just for my new branch on the server (as you suggested), although I don't quite understand how that would work.

Appreciate the feedback, nonetheless!

0 0
John Murray · Dec 5

In your example does IE.cls represent your interop production class? One of the longstanding source control challenges of the InterSystems interop architecture has been the monolithic nature of the prodclass. Deltanji transformed the scene a few years ago by implementing source control at the level of the individual business hosts within the prodclass.

Unless your project and my project overlap on one or more business hosts, we can work alongside each other in a shared development namespace and each promote our work to test (and ultimately to prod) independently.

1 0
Brett Saviano · Dec 5

I think in my ideal world, I would be able to make my own branch for my modifications, make changes, then commit them to the server when ready (thus deleting the branch). But if I want to be able to do that, I think we need to aim for a single-user environment, which means some sort of IRIS instance on my machine, or a dedicated environment just for my new branch on the server (as you suggested), although I don't quite understand how that would work.

This process is exactly what I was suggesting. Each developer gets their own IRIS, like they have their own copy of the code in the dedicated branch for the feature. Think of IRIS as the SDK, like the JDK for Java or Node.js for JavaScript. Your setup is complex, but if you have a process to set up your shared dev server then you can have the devs run that to set up their own servers. If developers won't be running tests that require the full setup, then the instance setup becomes even simpler. You can then have a CI/CD pipeline in your git provider that moves code to the shared test instance when it's committed to the main develop branch. With a setup like this, you can have as many devs working on as many projects as you like without them blocking each other. Any conflicts between changes will be resolved when the devs submit their code for a merge/pull request on your main branch.

0 0
Michael Derr · Dec 5

Interesting.  I'm curious if anyone has this particular setup with details to share?  For instance: does each developer have a local copy of IRIS on their laptop, or do they each have a dev instance on a server?  If they are using their laptops, are they using a virtual machine or container setup?  We have Windows machines but our IRIS instance is on Linux, so I imagine that would complicate things if the code a dev is working on references directory structure, system calls, etc.

0 0
Laurel James (GJS) · Dec 5

Hi @Michael Derr, 

It sounds like our source control solution, Deltanji, would be a great fit for your setup.

Deltanji is tightly integrated with the IRIS environment, providing source control for Productions and Health-specific artifacts directly at the workface.

It is also well-suited to concurrent development. It has high-granularity branching and merging, so multiple developers can easily work concurrently on separate branches. 

We can set Deltanji up to suit your workflow as it’s fully configurable. Developers can work locally, in their own sandbox, before pushing to the development server, or by using a shared Dev instance, with Deltanji controlling concurrent edits. We can then achieve the master source control state that you mentioned very easily, with code being moved through the Dev, Test and Prod environments.

Regarding your comment about differences between dev and prod Interop Productions, our Deltanji Production Component Driver, which allows granular management of Productions, will allow you to safely transfer interfaces from dev to test to prod without ending up having your live production talking to your dev endpoints. 

If working in Git is an organizational requirement, we have a Git Integration, so you can manage your IRIS artifacts with Deltanji, and then push to a Git repository as an upstream record of the changes.

Our website has more information: georgejames.com/deltanji. We’d be happy to give you a demo as well, just DM me, or my email address is laurelj@georgejames.com.

Laurel

0 0