#Embedded GIT initial setup question with IRIS for Health 2025.1.3
We have a long running InterSystems Engine with an Interface Development Team. We have implemented basic interface and code development processes using mostly manually created helper tasks and functions.
We are looking to upgrade these processes by installing and starting to use Embedded GIT in our DEV spaces first. We will not use it to deploy changes to PRODUCTION at first, keeping our same current process that the team is very comfortable with.
We plan to start by using the BASIC mode in GIT, to avoid confusion over multiple branches and other version control functions. (We will crawl, walk, then run since we are not a team of software developers). We will start slow but eventually move to a more normal use of GIT source control, eventually even deploying to PROD with it, but this will take a while.
Questions:
When we install on our DEV servers first, is there a way to also install GIT and Embedded Git package on our PROD servers, so we can export a baseline of all interface code and piece for use in DEV spaces? (We have a way to do this manually without a GIT baseline export, but feel the PROD baseline export would be cleaner and have less issues.)
Is there a way to do this without enabling source control in PROD, or at least without requiring it to be used? (Even better would be allowing us to export baselines from PROD -AND- get basic change tracking on changes to PROD items, without a lot of overhead for our interface developers at first.)
Comments
You can install Embedded Git on your PROD servers as software, and you can also make it available instance-wide via %ALL using:
do ##class(SourceControl.Git.API).MapEverywhere()
This creates mappings so all namespaces on the instance can use the version installed in the current namespace, but each namespace still has to be configured independently. [1]
For installation, the package can be installed with:
zpm "install git-source-control"
or from a downloaded release archive with:
zpm "load /path/to/archive/git-source-control-release.tar.gz"
and setup is then done with:
do ##class(SourceControl.Git.API).Configure()
That configuration step is what initializes settings and can also initialize or clone a git repository. [1]
On your baseline-export question specifically, the available material shows that Embedded Git includes “a command-line utility to do a baseline export of items in a namespace,” and newer releases add that baseline export includes decomposed production items when production decomposition is enabled. [2][1]
For your question about doing this on PROD without enabling source control or without requiring it to be used, the material here does not describe a documented mode where Embedded Git is installed solely for baseline export or change tracking while source control remains disabled. What it does say is that namespaces must be configured independently, and Embedded Git’s purpose is to intercept edits so changes are reflected in the filesystem and git repository. [1]
If you want PROD or another non-development namespace to participate in a Git-based flow later, one documented approach is to configure Embedded Git there as well and “do a git pull there to load the incremental diff from a branch corresponding to the environment.” Changes deployed through Git are also logged in SourceControl_Git.DeploymentLog. [3][4]
Important : if using source control for interoperability, check the “Permit Enabling Automatic Refresh of Management Portal Pages” box in the management portal, at the page: Interoperability > Manage > Configuration > Interoperability Settings. This mitigates a potential for lost work. [1]
For your proposed phased rollout, the documentation also shows there is a “basic” mode intended to simplify working with Git in more prescriptive workflows, including a sync operation and branch-handling simplifications. [2]
Sources: