15
5.8K

Written by

Timothy Leavitt
Senior Development Manager at InterSystems Corporation
STAFF
Follow
Announcement Timothy Leavitt · Nov 8, 2021
Open Exchange

Git for Shared Development Environments

#InterSystems IRIS #InterSystems IRIS for Health #Practices and Patterns #Embedded Git #Git #GitHub #Interoperability #InterSystems Package Manager (IPM) #Open Source #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
ImageImage

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-develop…

Check the related application on InterSystems Open Exchange
Related posts
Show all
Discussion (51)10
Log in or sign up to continue

Comments

Ben Spead · Nov 8, 2021

Great job @Timothy Leavitt and team!! This been a significant need for some time in order to support organizations that work in a shared-dev model, as well as those looking to connect the source controlled SMP pages to Git.  I look forward to seeing how this enables out community to make more thorough use of source control!  

0
Timothy Leavitt  Nov 8, 2021 to Ben Spead

Thanks @Ben Spead! And just to be clear, this isn't just for those working in shared, remote development environments - I anticipate this simplifying a lot of my work on Open Exchange projects even with local instances and VSCode.

0
Ben Spead  Nov 8, 2021 to Timothy Leavitt

Thanks @Timothy Leavitt for that detail.  In what way will these hooks be superior to the existing client-side VSCode hooks for Git?  I am interested in understanding the additional benefit for local instance work

0
Ben Spead  Nov 8, 2021 to Ben Spead

@Timothy Leavitt - I may be able to answer my own question here ... are the additional benefits the visual branch UI that is build into the IDE and the package manager awareness?

0
Timothy Leavitt  Nov 9, 2021 to Ben Spead

There's great IDE integration for VSCode for local git repos; really it's the package manager awareness that's key.

Use case: I find a bug in one of my project's dependencies Assuming it's been loaded from my local filesystem rather than by zpm install, I can just fix it directly via an isfs editing mode and it'll be reflected on the filesystem.

0
Ben Spead  Nov 9, 2021 to Timothy Leavitt

Makes sense - thank you for describing the use-case

0
Steve Pisani · Nov 20, 2021

Hi Tim, this is great, we spoke about this a while back and so glad you managed to get this out !!.  I've downloaded/installed it and will be using it for a project pretty soon.

Thanks again !

0
Timothy Leavitt  Nov 22, 2021 to Steve Pisani

@Steve Pisani glad to hear you'll be using it - your feedback (via GitHub issue, email, Teams, or carrier pigeon) is certainly welcome!

I know it took a long time to get this out, but better late than never! Shout out to @Sarmishta Velury and Adewale Adewuyi (who I can't tag) for helping to make it happen. :)

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

0
Eduard Lebedyuk  Dec 13, 2021 to Steve Pisani

Use three repos: dbLib, dbA, dbB.

Add dbLib as submodule to both dbA and dbB.

0
Craig Regester  Dec 13, 2021 to Steve Pisani

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
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
Craig Regester  Feb 13, 2022 to Steve Pisani

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
Evgeny Shvarov · Jan 15, 2023

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
Evgeny Shvarov  Feb 12, 2023 to Evgeny Shvarov

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
Scott Roth · Feb 8, 2023

Without having to go into each individual piece of code to add it to the git repository, when creating a new repository is there a quick way to import all the existing code from the name space into the Repository?

0
Ben Spead  Mar 24, 2023 to Scott Roth

Calling @Timothy Leavitt to weigh in on this when we gets the chance.  @Scott Roth - is your source already on disk or are you looking to dump it all out of the Namespace and to disk?

0
Scott Roth  Mar 24, 2023 to Ben Spead

Timothy and I have already been in contact and had discussed this in the past. As of right now I have put that on hold here at OSUWMC due to other priorities.

0
Ben Spead  Mar 24, 2023 to Scott Roth

okay, thanks Scott for the that update

0
Evgeny Shvarov  Mar 24, 2023 to Scott Roth

If you go with IPM+Git-source-control you can use wildcards as "MyApp.PKG" which will consider included all the classes in MyApp class package.

0
Mathew Rimmington · Nov 22, 2023

Whilst exploring how the company I work for could get source control up and running for our development environment I came across this announcement and am intrigued. However, I'm a bit confused about whether this is now out of support.

The link to the page here: https://openexchange.intersystems.com/package/Git-for-Shared-Development-Environments has a line at the top stating "This application is not supported by InterSystems Corporation". The phrasing of this is ambiguous, I can't quite tell if it means that the product is out of support and that people shouldn't use it, or whether the product is just not maintained by InterSystems themselves.

I thought I'd give it a go, but installing the package manager crashes on installation while using the instructions found here: https://openexchange.intersystems.com/package/Git-for-Shared-Developmen…. I did notice that there is an issue logged for it here: https://github.com/intersystems/ipm/issues/432.

Does anyone know whether this avenue for source control is effectively closed?

0
Ben Spead  Nov 22, 2023 to Mathew Rimmington

@Mathew Rimmington - this is an open source package which is written and maintained by InterSystems employees for the good of the Community, but doesn't have official support in the same way that customers have official support for InterSystems IRIS or HealthShare.  

This package is very much still strongly recommended for use and new sites are coming on board all the time.  We continue to invest in it and see it as a valuable tool for developers using a shared-dev model on InterSystems products.

In terms of the issue you are seeing, what InterSystems product are you using, and what specific version?  We will definitely help you work through the issues as much as we can.

CC: @Timothy Leavitt , @Pravin Barton 
 

0
Enrico Parisi · Dec 21, 2023

Is internet connection a requirement?

It seems is not possible to download and install it without using ZPM that require internet connection.

Not every server has internet connection.

Enrico

0
Enrico Parisi  Dec 22, 2023 to Ben Spead

Well...installing a ZPM registry require ZPM itself and internet connection.

Additionally, in environments with no internet connection adding a new server (or docker) with internet connection just to install a source control software does not sound like "a solution".

I understand that ZPM is simple and handy, but why not releasing a stand alone installer that can be downloaded and installed without ZPM?

Enrico

0
Evgeny Shvarov  Dec 27, 2023 to Enrico Parisi

Then when you need to install ZPM module without Internet do:

USER>zpm "load /path/git-source-control-2.3.0.tz"
0
Evgeny Shvarov  Dec 22, 2023 to Enrico Parisi

In addition to what folks said ZPM package is a tz tarball file which you can download in advance and install without internet too.

0
Enrico Parisi  Dec 28, 2023 to Evgeny Shvarov

Thank you for ll the info, I was able to install git-source-control and I'm....fighting testing it.

I think that the main problem with OEX software is the lack of information/details/documentation on how to install, configure and the use them.

Even ZPM itself suffer this problem, I found nowhere that a ZPM package can be downloaded as  tarball and installed using the load command.
Where is the url for downloading the the tarballs for the ZMP packages reported/documented?

The git-source-control has very (very, very....) limited documentation/information on any aspect, from configuration to usage. Often it's a reverse engineering activity  to figure out how it (should) work.
The feeling is that is a half backed software that has been abandoned.

Nevertheless I keeping fighting testing it.

0
Evgeny Shvarov  Dec 29, 2023 to Enrico Parisi

These are good points. IPM(ZPM) is officially supported now by InterSystems, so I'm tagging @Bob Kuszewski and @Timothy Leavitt on providing more information.

Here is the current documentation of IPM and it contains the information on how to load from tarballs here.

As for the option to download the package tarball it is indeed not very documented as it is a relatively rare case that people cannot use Internet to install the community package. 

Tarball can be downloaded from the community IPM Registry REST API requested in a format:

https://pm.community.intersystems.com/download/[package-name]/-/[packag…

e.g. here is the URL for git-source-control:

https://pm.community.intersystems.com/download/git-source-control/-/git…
 

0
Evgeny Shvarov  Dec 29, 2023 to Evgeny Shvarov

Technically tarball downloading feature refers to ZPM Registry package, which is intended to host IPM packages. And as folks mentioned above you can use it as the private registry hosting in your organization with the option to proxy some public packages.

I filed the ticket to update the documentation on tarballs.

And I think it makes sense to add the link to tarball download in Open Exchange for IPM packages.

0
Bob Kuszewski  Jan 3, 2024 to Evgeny Shvarov

Sadly, IPM/ZPM is NOT (yet!) officially supported by InterSystems

0
Timothy Leavitt  Jan 4, 2024 to Enrico Parisi

@Enrico Parisi I appreciate all of your feedback, and your patience. Regarding tarball installation, I've created another issue for git-source-control on that topic (https://github.com/intersystems/git-source-control/issues/310) as well as one for IPM more generally (https://github.com/intersystems/ipm/issues/436).
git-source-control is not officially InterSystems-supported, though it is maintained by people at InterSystems as a service to the developer community. The project certainly has not been abandoned, and there's actually an ongoing effort this month/next to deal with some of the rough edges (now to include your observations around CSP application mapping configuration). I'm personally committed to making it not feel half-baked.

0
Enrico Parisi  Feb 22, 2024 to Evgeny Shvarov

Excellent! Well done 👏

0
Mark OReilly · Jun 28, 2024

Hi: 

I added a query in the q&a a month ago, as we are ready to use this my question was:

In a shared Mirrored environment where do you put the local git folder/ where is best. 

What happens if the server the local git goes down does this have any impact on any development on live while the local git isn't available?

0
Timothy Leavitt  Jun 28, 2024 to Mark OReilly

Sorry we missed that. I started to look around for best practices and forgot to circle back.

It's a fantastic question, and I think your gut feeling from https://github.com/intersystems/git-source-control/discussions/343 is correct - the local-to-the-server repo should be in a place accessible from all mirror members, provided you can do this in a way that doesn't introduce a single point of failure operationally.

If that location is unavailable, you won't be able to do development, but operations on the running instance shouldn't be impacted otherwise (and that location being unavailable would be something that needs to be fixed immediately anyway).

0
Ben Spead  Jun 28, 2024 to Timothy Leavitt

if the folder includes files referenced by the running instance (xslt or js) then it's absence would have an impact on those functions which try to use the files at runtime 

0
joseph caroè · Mar 25

Hello, I have a question. We've installed this plugin on our remote development iris instance. I've been testing it a bit, and since this should be a plugin for "shared development environment", i thought each developer could create a branch and when checking out to that branch "locally" (meaning: In VSC, using the GIT extension for checking out) the branch would be checked out only for the developer. Instead, it seems "local branches" are shared for the namespace, so multiple devs cannot work together at the same time on the same namespace on different branches. Is the only solution having multiple dev environments, one for each developer?

0