Question
· Jan 17

Syncronizing Productions between DEV environments

Hello everyone! This is my first post into the developer community and one that I hope is fairly simple to answer. In our environment we currently have 3 different Test environments for testing before migrating code to our Prod environment. Currently we are working on establishing a source control method using Git in house which has been a bit of a struggle. We have also had developers that had used different test and migration methods in the past which has caused some issues with keeping the different test environment in sync.

What I am looking for is an option to either copy a whole Namespace/Production from either the CRT environment or DEV environment to our INT environment for integrated testing. Currently the process that we use for code migration between environments is by using the Studio export and import method on projects that are created in Studio. Would that same approach be used to copy the whole Production and contained classes and Business services, Processes, and Operations? Should we use the Deployment Changes method under Interoperability in the Management Portal, and if we use this approach, if we are wanting to overwrite the productions that are currently in the INT environment with updated production components and code would we include the production classes and PTD files?

What I would like to be able to do is copy an entire Namespace/settings within registries over and overwrite the current data/settings with one from the higher test environment if possible.

 

Ultimately since we are migrating to GIT and VSCode, what approach would be useful in pulling down from a repo that we use?

Product version: HealthShare 2024.1
$ZV: HealthShare Unified Care Record 2024.1.0 Build: 1008
Discussion (7)3
Log in or sign up to continue

@Sean Brady - welcome to the D.C.!  Great question and you should get a lot of help here.

First, definitely watch the video linked by @Oliver Wilms in the earlier response.  It will help you understand how the InterSystems-based healthcare platforms tend to work best with the embedded source control paradigm due to how changes are made in the Management Portal and not just in VS Code.  

As you try to get Git set up, can you please confirm that you using the Embedded Git package?  https://community.intersystems.com/tags/embedded-git

You said you are having issues working with Git - could you please provide more details?

If you haven't, you should review the Branching Strategy doc on GitHub for Embedded Git (https://github.com/intersystems/git-source-control/blob/main/docs/hcc.md#general).  While it is in the HealthConnect Cloud section, @Pravin Barton has assured me it is generally applicable.

While you are working towards getting a proper Git-based progression in place, you can use Deployment Manager in the Portal (but you should stop using this once you have Embedded Git working).  This is the easiest way to grab things in bulk and move them between environments.  

Please note that HealthShare Registries are not yet covered by Source Control / Change Control hooks, so you will need to move those by hand or via custom scripting.  Those will come later this year - see the Global Summit presentation on the topic here: https://www.intersystems.com/change-control-for-healthshare-intersystems/

Hopefully this is enough to get you rolling.  Let us know what questions you may have!
 

Going to give the video a watch now, as for the GIT issues we are experiencing it may just be user error and working with different team ownership over Healthshare pieces. The Management/Admin side of things is owned by another team than the developers and Admin is putting GIT into place. Currently they are implementing the Embedded git process and our developers have been hitting some snags with merging branches with main and then getting the code migrated to our next environment. The pipeline process is not there yet, just branching and source control over our lowest DEV environment. The push to use vscode over studio is there but the processes have not been migrated so we are still having to fall back to studio for deployments. The other side of things is the devlopers currently working on projects including myself are used to J2's Workbench Tools and GIT process which may have spoiled us.. haha

Thank you for the directional points on the embedded-git and git-source-control docs and strategies. Those will definitely help!

Since the approach sounds like to use Deployment Changes till the pipeline is in process for Git. If I am not caring about what is currently in a production in the target environment as its out of sync by a large degree. To bring it back into sync would I add the production class and ptd and all classes and ptd that I would like to be migrated or would adding the production class and ptd to the export cause any issues since there is already a production class present?
 

@Sean Brady - per "The push to use vscode over studio is there but the processes have not been migrated so we are still having to fall back to studio for deployments." ... FYI, when you use Embedded Git (or any Serverside Source Control toolset) you can use either VS Code and Studio (or both!).  The IDE triggers the behavior on the server so either should kick off the same behavior.

I am sorry but I can't answer your question about deployment manager as I have always relied on source control and automation tools based on that (I have been spoiled by that ;) ). 

If you are hitting merge conflicts I am going to go out on a limb and guess that these are in the Production Class?  If so then I highly recommend that you look at using Production Decomposition which solves this issue by allowing Embedded Git to manage PTDs rather than the Production Class as a whole - https://github.com/intersystems/git-source-control/discussions/519

We also have a standing weekly meeting for Embedded Git users to provide updates on features and 'office hours' for questions.  DM @Pravin Barton if you want to get an invite.