Multi-Namespace Deployment #78
Replies: 4 comments 6 replies
-
|
The general approach we use/recommend is tracking code separately based on the namespace it lives in, and using the source control extension to prevent editing code that's mapped from a non-default code database. That said, if there's a lot of demand we could consider this for git-source-control. |
Beta Was this translation helpful? Give feedback.
-
|
I think I found a satisfactory way to handle this using a single repo and multiple namespaces (without any changes to this source control impl needed) but could you speak to your last statement a bit more: "using the source control extension to prevent editing code that's mapped from a non-default code database." How do you mean? How does this source control extension prevent editing code mapped from a non-default code database? |
Beta Was this translation helpful? Give feedback.
-
|
Related discussion #90 (since sc-list would need to respect namespaces) |
Beta Was this translation helpful? Give feedback.
-
|
Hi - I thought about multi-namespace deployments further. Firstly we all agree that for single-namespace deployments, where code actually resides in multiple databases (eg %ZSTART, or a code library database) then, what we have today works - as long as the code also exports code mapped from databases other that the default code database. All assets can be exported, and, on deployment, if the target environment is configured as the development w/to mapping, then, all code imported will just find its right place in the specific source database it belong in. So that's ok. (case 1) Often solutions comprise of multiple namespaces. A common use case is for those heavily invested in Interoperability solutions which as we are aware, each integration solution must run in its own namespace. This is not an issue if each namespace is 'wholly contained' and separated in terms of contributing code for each namespace, because in that case there is no issue either. (case 2) Only when there are underlying databases that are serving conde to multiple namespaces, do we have a problem. As things stand right now, (assuming mapped code is exported), then, there would be copies of the same code in different branches of your git repository if users edit code X from namespace A, and namespace B. (case 3) I think in order to allow flexibility of deployment we would need to enhance git-source-control with the following:
b) introduce logic which, on export of code needs to resolve the physical location (database) of the code being exported, and, construct the export path for file export from IRIS, honoring this special string. If it is not defined, then, continue processing as the current logic exists. c) Whilst we are at it, why not also allow the special string {namespace}, (eg C:\ProjectsCode\src{namespace}). - this way (as in for Case 2 above) where there are multiple namespaces that do not share source code, the git-source-control configuration global can be defined once and mapped using the %ALL Namespace definition ensuring all namespaces with solutions follow the same git-source-control settings. Thoughts ? (I have a site running 7 IRIS Healthcare productions sharing common code, on one instance, for which this would be useful !) Steve |
Beta Was this translation helpful? Give feedback.
-
|
I was playing with this idea bit more with the latest commits over the weekend. I think the code can almost fundamentally support this concept now as-is - the main blocker is sc-list.txt (which I'm not thrilled with being included in our remote repo anyway as it's just clutter but not a showstopper. Though curious why sc-list.txt was utilized as a source control managed file vs using the Globals approach many of the existing solutions utilized to track SC managed files.) As the Settings area already allows for specifying folder pathing for cls/rtn/etc, I can insert the namespace name in front of each 'Mappings' item and it outputs exactly where I want. This allows me to initialize each namespace with git-source-control, setup the mappings appropriately, and when I push to the remote, it places in the right spot - beautiful. But the blocker is sc-list.txt as it ignores any mapping setting and always goes into the root of the defined 'temp folder' therefore clashing with other namespaces also wanting to use the same spot for sc-list.txt. If sc-list.txt can have it's own 'mapping' it respects, I believe the problem is solved and git-source-control can be utilized with many different variations of source control methodologies/preferences. (Or if sc-list.txt can be replaced with Global references managed by the namespace it's active on, that'd also take care of it imo) Curious on thoughts around this idea. Also interested in a way to control the initial git init / clone flags used - I can do this outside the UI, i.e., instead of using the Production source control menu, I can handle the init myself in the command line and do a sparse checkout of the remote branch that only pertains to the namespace I'm after. But would be relatively straight forward to roll this into the Configure() setup along with the remote add since we're already capturing the location of the SSH Deploy Key. |
Beta Was this translation helpful? Give feedback.
-
|
curious @isc-tleavitt, why do we use use sc-list.txt as a file as opposed to storing the data in the DB? |
Beta Was this translation helpful? Give feedback.
-
|
To share a bit of where this is a really valuable approach to me (as a healthcare org)... new HealthShare UCR deployment. Generally has one or two namespaces handling most code (HSCUSTOM/OUR_ORG_NS_WITH_CUSTOM_CODE mapped via %All), and then several other namespaces spread across the same instance or even separate instances that are very bare generally... so you would end up with something like:
If there's something fundamental I'm missing about a way to easily source control all these separate namespaces that generally just have their Production as the only specific class (everything else mapped), let me know. Productions themselves I found don't really handle mapping from other namespaces (like our custom code namespace) - it's there... but as soon as a change is made in the UI Production Config things get out of sync between the original code-only NS and the actual production-owning NS. |
Beta Was this translation helpful? Give feedback.
-
|
@isc-bspead sc-list.txt is a holdover from the original extension this was copied from. The use case is primarily around import, but really that's covered much more fully by the package manager at this point. I think we should move to a global. |
Beta Was this translation helpful? Give feedback.
-
|
re: sc-list.txt, filed #120 |
Beta Was this translation helpful? Give feedback.
-
|
#214 and #215 pick up this concept. (It's come up again in a customer call.) |
Beta Was this translation helpful? Give feedback.
-
In the interest of reducing repository sprawl, what are the current limitations of having a repo (and git-source-control) support multiple namespaces?
If you review the code I shared, you may note that injected a lot of logic to support $namespace in the global I was using to track checkouts, adds, etc. This allow me to create a repo structure that at the top level started at the namespace and once within, then broke out to sub folders as appropriate (cls, csp, lookuptables, etc.)
e.g.,
The idea was we could have the MYCUSTOMLIBNS own a lot of our common custom code classes that could be used across multiple interoperability namespaces (MSNS1, MYNS2) through package mappings but when it comes to source control, we'd only want the code within that namespace folder (e.g., MYNS1) to be code owned by that namespace - thus running a test on the package path to determine if it was mapped or not before allowing it to be added to that namespaces' export folder.
This separation also allows for reduction in duplication of code while still allowing the ability to see all the code related to an Interoperability Namespaces' operation to be in one repository. MYNS1 has dependencies on MYCUSTOMLIBNS in this case.
Does that make sense? Is it as simple as mapping the ^SourceControl( global across multiple namespaces and maybe having a place in the settings to specify the namespaces to include/monitor?
Beta Was this translation helpful? Give feedback.
All reactions