|
| 1 | +# Instance-wide Git Configuration |
| 2 | + |
| 3 | +## Motivation |
| 4 | +Systems on InterSystems products will often have code in multiple namespaces. This is especially true in interoperability use cases, such as IRIS for Health and HealthShare, because each namespace may only have a single running production as a time. By default, Embedded Git is isolated to a single namespace. This allows you to configure Embedded Git independently with an independent local repository for each namespace. Instead you may want to control all of the code across an IRIS instance with a single local repository. This has several benefits. |
| 5 | +- Code reuse: shared code can be more easily reused and updated if all namespaces are sharing a single repository |
| 6 | +- Ease of configuration in IRIS: sharing Git configuration between namespaces is easier than configuring each namespace for Git separately |
| 7 | +- Ease of configuration in the Git remote: creating separate remote repositories in GitLab/GitHub/etc. becomes impractical when there are a large number of namespaces. |
| 8 | + |
| 9 | +The simplest way to do this is to have all namespaces with custom code share a single routines database. The diagram below illustrates how to do this: |
| 10 | +```mermaid |
| 11 | +graph TD |
| 12 | + classDef namespace fill:#0074D9, color:white, stroke:#0074D9; |
| 13 | + classDef database fill:#0074D9, color:white, stroke:#0074D9; |
| 14 | + classDef hscustom fill:#2ECC41, color:white, stroke:#2ECC41; |
| 15 | + classDef config fill:#808080, color:white, stroke:#808080; |
| 16 | + classDef allnamespace fill:#0074D9, color:white, stroke:#0074D9; |
| 17 | + |
| 18 | + %% Legend classes |
| 19 | + classDef legend-blue fill:#0074D9, color:white, stroke:#cccccc; |
| 20 | + classDef legend-green fill:#2ECC41, color:white, stroke:#cccccc; |
| 21 | + classDef legend-pink fill:#FF69B4, color:white, stroke:#cccccc; |
| 22 | + classDef legend-gray fill:#808080, color:white, stroke:#cccccc; |
| 23 | +
|
| 24 | + D([Data-A]):::database |
| 25 | + E([Data-B]):::database |
| 26 | + F([Data-C]):::database |
| 27 | + A[Namespace-A]:::namespace |
| 28 | + B[Namespace-B]:::namespace |
| 29 | + C[Namespace-C]:::namespace |
| 30 | + ALL[%All Namespace]:::allnamespace |
| 31 | + G([HSCUSTOM]):::hscustom |
| 32 | + H([CONFIG]):::config |
| 33 | +
|
| 34 | + A --> D |
| 35 | + B --> E |
| 36 | + C --> F |
| 37 | + A --> G |
| 38 | + B --> G |
| 39 | + C --> G |
| 40 | + ALL --> G |
| 41 | + ALL --> H |
| 42 | +
|
| 43 | + %% Legend |
| 44 | + subgraph Legend |
| 45 | + L1["Globals DB"]:::legend-blue |
| 46 | + L2["Routine DB"]:::legend-green |
| 47 | + L3["IRIS Config Global Mapping"]:::legend-pink |
| 48 | + L4["Git Config Global Mapping"]:::legend-gray |
| 49 | + end |
| 50 | +
|
| 51 | + linkStyle 0 stroke:#0074D9, stroke-width:2 |
| 52 | + linkStyle 1 stroke:#0074D9, stroke-width:2 |
| 53 | + linkStyle 2 stroke:#0074D9, stroke-width:2 |
| 54 | + linkStyle 3 stroke:#2ECC41, stroke-width:2 |
| 55 | + linkStyle 4 stroke:#2ECC41, stroke-width:2 |
| 56 | + linkStyle 5 stroke:#2ECC41, stroke-width:2 |
| 57 | + linkStyle 6 stroke:#FF69B4, stroke-width:2 |
| 58 | + linkStyle 7 stroke:#808080, stroke-width:2 |
| 59 | +``` |
| 60 | + |
| 61 | +## Usage Notes |
| 62 | +- Instance-wide source control is "all-or-nothing". There may not be some namespaces with shared source control configuration and other namespaces on the same instance with different source control configuration. This is because %All mappings in IRIS may not be overridden with namespace-specific mappings. |
| 63 | +- Instance-wide configuration may not be used on TrakCare/IntelliCare instances. |
| 64 | +- Two namespaces may not have the same interoperability production running at the same time. |
| 65 | +- With instance-wide configuration, system default settings will be shared across all namespaces. * should not be used in system default settings unless they truly should be applied across the entire instance. |
| 66 | + |
| 67 | +## Configuring instance-wide source control |
| 68 | +- Create a new database CONFIG for Embedded Git configuration.[^1] |
| 69 | +- Create a shared routine database for all user-defined namespaces, referred to as HSCUSTOM through the rest of this document.[^1] |
| 70 | +- Set HSCUSTOM as the routines database for all user-defined namespaces. |
| 71 | +- Create global mappings for interoperability and localization configuration to the HSCUSTOM database.[^1] |
| 72 | +``` |
| 73 | +[Map.%ALL] |
| 74 | +Global_Ens.Config.Item*=HSCUSTOM |
| 75 | +Global_Ens.Config.Production*=HSCUSTOM |
| 76 | +Global_Ens.Rule=HSCUSTOM |
| 77 | +Global_Ens.Rule.Targets=HSCUSTOM |
| 78 | +Global_Ens.Config.BusinessPartner*=HSCUSTOM |
| 79 | +Global_Ens.Config.DefaultSettings*=HSCUSTOM |
| 80 | +Global_Ens.LookupTable=HSCUSTOM |
| 81 | +Global_Ens.Util.Schedule*=HSCUSTOM |
| 82 | +Global_EnsEDI.Description=HSCUSTOM |
| 83 | +Global_EnsEDI.Schema=HSCUSTOM |
| 84 | +Global_EnsEDI.X12.Description=HSCUSTOM |
| 85 | +Global_EnsEDI.X12.Schema=HSCUSTOM |
| 86 | +Global_EnsEDI.ASTM.Description=HSCUSTOM |
| 87 | +Global_EnsEDI.ASTM.Schema=HSCUSTOM |
| 88 | +Global_EnsHL7.Description=HSCUSTOM |
| 89 | +Global_EnsHL7.Schema=HSCUSTOM |
| 90 | +Global_Ens.Conf.Credentials*=HSCUSTOM |
| 91 | +Global_Ens.SecondaryData.Password=HSCUSTOM |
| 92 | +Global_IRIS.Msg=HSCUSTOM |
| 93 | +Global_IRIS.MsgNames=HSCUSTOM |
| 94 | +``` |
| 95 | +- Create global mappings for source control configuration to the CONFIG database. |
| 96 | +``` |
| 97 | +[Map.%ALL] |
| 98 | +Global_SYS("SourceControl")=CONFIG |
| 99 | +Global_SYS("SourceControlClass")=CONFIG |
| 100 | +Global_Studio.SourceControl*=CONFIG |
| 101 | +``` |
| 102 | +- Run `##class(SourceControl.Git.API).Configure()` in one namespace to set source control configuration globals. |
| 103 | + |
| 104 | +[^1]These are candidates to be automated through a new `EnableInstanceWide` method in the Embedded Git API. |
| 105 | + |
| 106 | +## Migrating existing items into the shared routines database |
| 107 | +If there is custom code already existing in the routines database, creating a new shared routines database will delete them. Assuming these already exist in separate Git repositories, they should all be copied into a single Git repository and imported into new database with the Import All option. |
0 commit comments