Comparing code on running servers
Is there a way of comparing code running on two Ensemble servers - ideally excluding certain types of difference?
We are a new team working in HealthCare (lots of HL7, some web-services). As well as doing new development on local servers with suitable source control, we have a large code base we've inherited from an external supplier for which we have no log of versions or differences. We have a live server and test server - and we've stumbled across a couple of places where there are differences in logic in addition to the expected differences in endpoints. Is there any way of systematically comparing the code running on those two servers, so we can identify all the differences? Eg a script to run against exports of the code created on the two servers that intelligently compares and highlights differences, but excludes things like differences in endpoints?
Hi Colin,
I created a utility a few years back which I have open sourced to:
https://openexchange.intersystems.com/package/ompare
It will show significant differences in Classes, Routines, Lookup Tables, HL7 schemas, Include files, Namespace mappings.
ie: It is clever to ignore non-functional differences for example:
This helps a lot for uncontrolled environments where updates have been integrated manually, in a different order.
The SQL profile can help diff anything with a SQL projection so can include: Production settings, Schedule Tasks, CPF, etc.
It works with flatfile exports and imports, so systems can be disconnected / on different networks.
Will happily diff 5 or 10 systems side-by-side.
The intention is for a client install that only includes the profilers and schedule.
Meaning the reporting side web pages do not need to be installed to servers only being profiled for difference signatures.
If needed it can effect code diffs just via the thumb-prints, without exporting actual code, useful for secured code scenarios.
Also if looking to upgrade Ensemble, there is a zero-install version of same compare tool that might highlight some useful platform differences https://openexchange.intersystems.com/package/Ompare-V8
Cheers,
Alex
I usually follow these steps when I have two similar but distinct codebases:
Commit from step (3) would have all the differences between LIVE and TEST. I assume the code on TEST is newer, so that should be a later commit, but it you want to, you can swap the export order.
Before making a commit (3) you might want to remove trivial differences such as whitespaces, etc. Also Gitlab has a compare mode for commits which automatically ignores whitespace differences.
I like what @Eduard Lebedyuk suggested.
But I also suggest to have the repo (GitHub, GitLab, whatever else git) at first place and deploy from the repo to the production server e.g. via IPM package manager.
Thanks for suggestions so far.
One challenge is our organisation is very wary of installing any additional code (as Alex suggested) or hooking up something like VS Code, to the live server, which is passing patient information between the various hospital systems... The test system has a little more flexibility, but organisation is a bit twitchy!! Would a plausible path be to sort of follow Eduard's suggestion, but:
Yes, that'll work. Just need to be careful to export everything. Classes? Routines? Custom Schemas? LUTs? SDS?
Ompare can also be run against exports that had been re-imported to clean namespaces for profiling locally.
It won't help for comparing namespace mappings or SQL, but it could still do the Lookup table differencing for you.
The approach either GIT / Ompare for actual diff is one choice.
With regard to achieving an export, I would suggest to use Studio on the target Ensemble Instance to create a "Project" for exporting.
Then add the respective Classes, Routines, HL7, include, Rules and any other components.
For lookup tables if the version is too early for visibility of "LUT" types, these can be exported by manually adding for example: Ens.LookupTable("MyTableName").GBL to the project, for each lookup table.
If you have a project on the server it is less error prone and quicker to have an existing export project to add items next time.
When you import with studio to report instance / git instance, you will have opportunity to double check which items you do actually want to import.
Hope that helps.
Thanks all for responding. Really only adding this message so I can try and mark the question as answered - since there are the two approaches (ompare and using git/repo tools), not wanting to mark one or other as the answer, since both have merits and may be helpful for different situations. I suspect we'll try the git/repo tools approach first, given our particular mix of platform and experience.
I think DC lets you mark more than one response as an answer.
💡 This question is considered a Key Question. More details here.