Which is better for deploying new HealthShare environments and incremental updates - %Installer or Ensemble -> Export Production?

Question

Question

Grace Fiamengo · Feb 28, 2019

This is my first post, I have only been using Healthshare for a year.

We support multiple Healthshare test and development environments. We are trying to come up with the best solution for building an environment from scratch, as well as incremental updates. I am interested in hearing the pros and cons between using the Ensemble -> Export Production feature versus creating custom classes to do the install and setup.

At the moment we have custom classes (one for Access gateway, one for Registry, etc), that installs Healthshare and our custom settings using the %Installer tool. I did not write these, but I have used and updated them when needed. For incremental updates we take a snapshot of the environment (it's Unix if that matters), then import the XML file and then manually update any settings needed. We've had enough of those incremental updates now that I feel like I need to go back and modify the custom setup classes to include these new settings, which is why I am starting to consider other options.

I have been playing around with the Ensemble -> Export Production option in the management portal. I really like that it creates a rollback file, that's a nice feature. My thought is, if I have one environment that has all the things already installed and working, I can export that production to a baseline file. Then when a new project comes along and the developer needs a fresh new environment, I just install that exported baseline file. As incremental updates happen, I install the XML in my baseline environment, configure any new settings, and then update my baseline file with the new stuff to use for any new environment requests that come along in the future. For existing environments, I am not sure if I could install that new baseline file or should just restore the XML and manually adjust any settings like we do now?

I have read through some posts on here and sounds like Export Production has had some bugs. This is the version we are currently running:

Cache for UNIX (Red Hat Enterprise Linux for x86-64) 2017.1.3 (Build 317_0_18518U) Tue Oct 16 2018 00:28:11 EDT [HealthShare Modules:Core:15.03.1007 + Linkage Engine:15.03.1007 + Patient Index:15.03.1007 + Clinical Viewer:15.03.1007 + Active Analytics:15.03.1007]

I have also heard that Ensemble tools don't always work well with Healthshare. So I am curious to hear from those with deployment experience, which do you think is the better way to go and why?

Thanks so much!

Grace

Discussion (4)1

Log in or sign up to continue

James MacKeith · Mar 6, 2019

Hi Grace

I defer to those with experience in the field to offer comparative advice but concerning the Production Export functionality:

For existing environments it is possible to use the Export for deployment from the Production configuration page for one or more items and not the whole production. This allows changing existing items or adding items to a production when deploying the export file. When changing an item the deployment code will disable the item first if it is enabled and then re-enable the item as necessary after the deployment has finished.

It is possible to remove items using the deployment functionality but for this one needs to use Ens.Deployment.Util APIs and not the GUI to create the removal deployment package.

Concerning settings - if you haven't seen perhaps System Default Settings might be appropriate (https://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY...).

An alternative use of System Default Settings by some sites is to use for the same values without having to enter per item - hence the option in the Export for deployment dialog to export deployable System Default Settings.

The Export from the Production configuration page attempts to identify what are linked items/code but might not be complete. This is the reason for being able to add Studio project contents to the export. In version 2017.2.0 we added detection of RecordMap classes to be included in the export.

Best wishes

James

1 0

score 0 · Answer 1 · 2019-03-04T07:51:16-05:00

I'm interested in this question.
Our team has historically been using the export tool in Caché Studio IDE, but I've started experimenting with the Portal Export/Deploy functionalionality.

With respect to the Portal Export/Deploy functionalionality:
Pro's: Rollback (but I've never used it)
Cons': What is included by default when exporting is not what you might expect. (It is easy to shoot yourself in the foot)

We are only using the 'Ensemble' components of HealthShare(HealthConnect), we have not started using the Healthshare specific functionality.

score 0 · Answer 2 · 2019-03-11T12:26:19-04:00

Thanks James. For incremental updates to existing environments, I could see how the System Default Settings with the Production Export functionality would work well. For now, our product is still in development and test phase, we don't have anything out in the real world yet. I am still not sure - for creating that initial install package for when we take this live, whether it is better to use the Production Export Functionality or create a custom install class. Besides system default settings, we have OIDs, LOINC codes, document info types, Registry configuration, Custom XML summaries and more. Right now the custom setup class creates those when the setup class is run in a new environment, and I am adding more to it based on recent development changes. I believe if I used the export functionality those settings would end up in the deployable file, but I need to get an empty environment up and running so I can test that. We are at version 2017.1.3, so not sure if we need to wait until 2017.2.0?

Take care,

Grace

score 0 · Answer 3 · 2019-03-12T10:56:54-04:00

I usually prefer ways when I can automate as most as possible. So, I would suggest, to use simple export but, and automate it, as you already use %Installer to automate installation.