Announcement
· Nov 8, 2021
Open Exchange

Git for Shared Development Environments

#Best Practices #Git #GitHub #Interoperability #ObjectScript #InterSystems Package Manager (IPM) #Open Source #InterSystems IRIS #InterSystems IRIS for Health #VSCode

If you're building solutions on IRIS and want to use Git, that's great! Just use VSCode with a local git repo and push your changes out to the server - it's that easy.

But what if:

  • You're collaborating with other developers on a shared, remote development environment and want to avoid concurrent editing of the same file
  • You're using editors based in the management portal for BPL, DTL, pivots, dashboards, etc. and want straightforward source control for your work
  • You're still using Studio for some things and/or occasionally jump back there from VSCode - or, your team has not yet fully embraced VSCode, and some team members still want to use Studio
  • You're working on a bunch of separate projects at the same time in the same namespace - say, several packages defined using the InterSystems Package Manager - and want to just work with all of them from one isfs editing view (rather than a bunch of distinct projects) with changes tracked in the proper git repo automatically

Then it wasn't so easy... until late last month, when we released Git for Shared Development Environments (Open Exchange / GitHub). You can get this extension using the InterSystems package manager:

zpm "install git-source-control"

Prior to this, the options for source control with Git were an old mostly-Windows-only, local development environment-only Git extension and a more recent Open Exchange project based on it but streamlining use a bit. There's also Port, which just deals with files and is version control system-agnostic.

What does git-source-control have that these packages don't?

  • Simple menu-based integration with git that works on any operating system
  • A git user interface to cover an expanding set of common git activities, without having to SSH over to the remote environment.
  • Concurrency control for multiple users working in the same environment at the same time. Once you make changes to a class/routine/etc., it's yours until you discard or commit your changes. (We do have ways around this when needed, though!)
  • Package manager-awareness: just zpm "load -dev /path/to/package" and, if /path/to/package/.git exists, changes to resources in your package will automatically be reflected in the right place on the server filesystem. The UI works with this too, based on the class/etc. from which it is launched.

All of this works from VSCode:

 
Spoiler

And Studio:

 
Spoiler

To give you control over and visual insight into your git repository:

 
Spoiler

We hope this enables your successful development of IRIS-based solutions, and welcome your feedback!

NOTE - To see the presentation launching this at the 2021 Global Summit, see this article: https://community.intersystems.com/post/video-git-gitlab-shared-developm...

Check the related application on InterSystems Open Exchange
Discussion (29)6
Log in or sign up to continue
Ben Spead · Nov 18, 2021

I would just like to point out that any attenders of Virtual Summit who missed Tim's presentation can still access the replay here: https://web.cvent.com/hub/events/90791fad-b517-47e6-a1ca-f6d419711986/sessions/a5d162c7-4c0d-4d07-a211-84d68c3c020c

People who didn't attend Virtual Summit should stay tuned as the content will be published by InterSystems Learning Services and made available for everyone to watch.

1 0
Steve Pisani · Dec 12, 2021

Hi.  In the real world, solutions are often made up of multiple namespaces, and code that exists in multiple databases where some databases are shared. For example nsA (running in namespace A) uses code from dbA, and dbLib. nsB uses code from dbB and also dbLib.

I would have thought that the GIT repository (or export folder) should have the option of being  built using the source Database of the component as part of the name in the path:eg:

/src/dbLib/cls...

/src/dbA/cls..

/src/dbB/cls...

On export, export logic resolves the true physical location of an item. 

Seperate Git Repositories per namespace is not the answer iether, as we don't want the dbLib code duplicated in multiple repositories.

@Timothy Leavitt 
​​​​​​Can you think of an enhancement, to this code that aligns export folder with actual dbname of exported item ? I would suggest perhaps the configuration global holding the export path, to allow for some sort of special string (eg "%sourceDB%") which is resolved at runtime.

Thoughts ?

Steve

1 0
Craig Regester · Dec 13, 2021

Agree with this 100% - the link @Timothy Leavitt shared is my post on this topic and would love to have your voice added to the discussion.

@Eduard Lebedyuk Generally agree your approach would be a good approach as well but the goal - having talked to Tim a bit - from my perspective/approach is to make this as seamless as possible for our low-code/no-code integration analysts and even engineers to a degree who can manage our shared-code libraries that are mapped to our integration namespaces from within the same repo as they are tightly intertwined.

0 0
Steve Pisani · Feb 12, 2022

Hi,

As this is git support for shared development,  multiple developers log into and share the same, remote server - are they still individually able to create GIT branches ? How will the server's local git repository identify one users items from another's ? I guess I'm struggling to see how this would actually with branches.

Should the IRIS users log in as their own IRIS user account ? Is this required ?

Thanks - Steve

0 0
Craig Regester · Feb 13, 2022

Yea branches are still possible and yes users should log in as their own users (this extension allows users to enter their own git user.name and git user.email to track commits properly)  - there is stash support to a degree and the ability for branching but given the nature of IRIS being “trunk-based development” at its core, of course those branches still compile against the same IRIS namespace. 

But this extension will continue to improve and expand! I’ve been helping out where I can and providing suggestions from the standpoint of organizations that are traditional integration teams belonging to patient-care-centric healthcare orgs and Tim and his team are doing an amazing job. 
 

please be sure to join the discussions occurring at GitHub, try out the extension to get a feel for it and provide your voice to the continuing expansion of the extension! We’ve made some tremendous strides via this process and I’m excited to see the evolution!

0 0
Evgeny Shvarov · Jan 15

Hi @Timothy Leavitt !

Trying git-source-control for client-side development. A lot works well!

Have a question though: I need to restart docker and have git-source-control set up. I exported the settings in ^SYS global and import it during docker build but source control doesn't seem working. 

Do I need to turn on anything else? Any other global or setting need to be made?

0 0
Evgeny Shvarov · Feb 12

Turned out, the following call should be executed to let source control start working:

do ##class(%Studio.SourceControl.Interface).SourceControlClassSet("SourceControl.Git.Extension")

Check Interoperability template to discover Git integration for Interoperability UI components. Production, Business Rules (old UI), Business Process and Data Transformations are supported.

Things to know:

1. Make sure the settings export changes in the folder you want, can be adjusted in the git-control UI.

2. Every Interoperability component should be first added to source control manually (in the git-control UI, add button).

3. Make sure you export the git-control settings too! They are in ^SYS global. @Timothy Leavitt , we also need source control for git-control settings ;) (Could be a ^git-control global name ?)

For now I use the following line to export it in a proper format and in a proper place, which I still call in a Terminal:

do $System.OBJ.Export("SYS*.GBL","/irisdev/app/src/gbl/SYS.xml",,.errors)

And I import it with the following setting in module.xml:

<Resource Name="SYS.GBL"/>,

a full module.xml example. 

4. @Timothy Leavitt , Would be great to have the UI to have the editable list of all the source-controlled elements. E.g. to easily transfer ^SYS global between projects. As the majority of settings for docker-enabled setups are the same, but the list of source-control elements is different.

@Guillaume Rongier , have a look! )

0 0