I am working on a custom Bahmni/OpenMRS deployment and have been facing several dependency and compatibility issues while building and running the stack from source.
My goal is to understand the recommended long-term approach for teams that want more control over the platform.
Is it considered a supported/recommended approach to:
Build Bahmni modules from source
Maintain our own Docker images for OpenMRS, Bahmni Apps, and related services
Manage OpenMRS module versions ourselves
Maintain a custom deployment pipeline and release process
Or is the expectation that teams should primarily use the official/prebuilt Bahmni images and customize configuration on top of those images?
For teams running production deployments with custom development, what is the common practice in the community?
I would appreciate guidance on:
Recommended architecture for custom deployments.
How much ownership teams typically take over OpenMRS/Bahmni module builds.
Best practices for maintaining custom Docker images while staying compatible with Bahmni releases.
I am in the process of figuring out something like this as well, though at our location we don’t want to build the whole of Bahmni + OpenMRS, just the minimal of what we need for some things we have customized.
As far as I can tell, it should be fully possible to maintain your own build system and/or fork the code, but I think a lot of things will be up to you to figure out. I’m sure there are people who can help, but what is supported is probably using the pre-built images.
So far for us, we are building/maintaining our own versions of:
a few custom opemrs modules (which interact with the frontend over REST api)
bahmniapps with some customization (the Bahmni frontend)
bahmni_config (Bahmni frontend configuration)
concept dictionary (just some additions on top of the stock dictionary from Bahmni from several years ago)
our own build of some of the services, especially pacs-integration, in order to integrate with our x-ray system and process
I’m in the process of setting up the Docker version of Bahmni, and trying to integrating some of these changes in a way to make it as easy as possible to maintain them and pull in upstream changes. I expect that our updates from upstream will be rare (every few years), and I anticipate each time it will take some effort to see what has changed from upstream and merge code and config changes.
One thing about using Docker that I’ve found helpful is being able to replace the image: lines in the compose file with things like build: ./openmrs. Then in a “openmrs” folder, have a Dockerfile which references the Bahmni image (ie FROM bahmni/openmrs:1.1.2) and then applies patches or layers some of my own things on top of it.
An alternative is to clone the git repos, run a build process to make your own Docker images, and then possibly push them to your own docker registry.
Sometimes it takes some effort to figure out what versions of docker images correspond to each other and to different tags or commits in git repos. For example the current bahmni-standard version references: