New post
Question
· Apr 8

Best Practices for Git Integration with Developer Namespaces in IRIS

#Embedded Git #Git #Source Control #InterSystems IRIS

Greetings,

Our team is transitioning to Git in the foreseeable future, and I'm trying to figure out how to design the best development workflow. Being new to IRIS, I am having trouble wraping my head around a few concepts.

Current Setup:

  • All code is hosted on a remote server
  • Each developer works in their own dedicated Namespace, on that server
  • Classes are locked to avoid conflicts
  • Committed code is imported into the Development NS, then redestributed to developers

Challenge:

Initially, I assumed we could replace this setup with Git Branches, following a typical workflow (one shared repository, developers work in feature branches, merge into staging). But I’ve realized that while branches isolate code, they do not isolate runtime environments the way namespaces do.

Question:

What are the architectural options here?

  • Is it common to assign one repository per namespace?
  • If so, how are changes across namespaces coordinated and merged into a staging or production namespace?
  • Has anyone transitioned from a "namespace-per-dev" model to Git, and how did you handle runtime vs. version control isolation?

Thanks in advance for any insight or examples of how this is typically done in real-world IRIS projects.

Edit: We're planning to use the git-source-control package (https://github.com/intersystems/git-source-control) and work with both, the deprecated Iris Studio and VSCode (based on Developer preference). This should also have some impact, as you cannot easily change branches within Studio if I understand correctly.

Product version: IRIS 2024.1
Discussion (2)4
Log in or sign up to continue
Timothy Leavitt · Apr 8

Hi @Alex Efa 

I'd recommend checking out Embedded Git: https://github.com/intersystems/git-source-control

The approach with Embedded Git is very similar to what you're doing. You want each developer to be able to work in their own feature branch and switch between feature branches easily, but this is a namespace-scoped operation, so it's still good practice for each dev to have their own namespace. Embedded Git manages synchronization of a git repo (on the remote server, alongside IRIS) with the contents of the database. This works both ways: do a git pull through Embedded Git, and it'll import and compile the updated code; change something in the database (e.g., in an isfs folder in VSCode or through a management portal interoperability editor), and it'll get exported to the filesystem in the right place.

Embedded Git includes tools for coordination/merging (although the actual workflow should be driven through merge requests in your git remote). Your staging/production namespace would also have Embedded Git configured; just do a git pull there to load the incremental diff from a branch corresponding to the environment.

We have a weekly stakeholder meeting / office hours for Embedded Git and would be happy to connect with you there; drop me a direct message with your email address and I'll add you to the invite.

0 0
Ben Spead · Apr 8

@Alex Efa   - I recommend that you take a look at using the Embedded Git open source package, which makes the power of Git available from within an IRIS instance (rather than using it client side which has shortcomings when it comes to things controlled in the SMP like Interop).  

This article may be of interest: https://community.intersystems.com/post/new-and-upcoming-embedded-git-fe...

Here is a helpful branching discussion on options for Embedded Git in our Health Connect Cloud product (the concepts would apply to any application of Embedded Git): https://github.com/intersystems/git-source-control/blob/main/docs/hcc.md.  You will see that it is quite common for developers to work in their own Namespaces on feature branches and then merge them in.  But this is only one of many models.

@Timothy Leavitt, @Pravin Barton  and @Nick Petrocelli can answer specific questions that you may have.
 

0 0