Join us this Thursday, Feb 27, at 13:00 UTC for our first CHT Dev Hour! Come connect with other folks from around the globe who are deploying, configuring, and/or developing software in the CHT ecosystem (or are interested in getting involved)!
The hour will have an open format with the goal being to discuss technical questions/challenges faced by those in attendance. No question is too big or too small! To provide a bit of structure for our time together, I encourage everyone to respond here on this thread with any topics they would like to discuss during the Dev Hour. This provides a convenient public place to see what folks are interested in talking about and we can continue to add to the list even during the session. (Also, if you see another post you are also interested in discussing, give it a to help gauge prioritization…)
(Don’t worry about including a bunch of explanation/context with your topics/questions on this thread. We can get into more details on the call. A brief summary here is fine!)
I’d love to hear from folks outside of Medic, but of course we all struggle with technical issues every day! I’ve been doing a lot of troubleshooting of a large CHT Core instance (>30M docs) which has me wanting to go through the CHT Sync deployment steps. Has anyone done this? Seems straightforward enough, but I’d love to hear from some one who’s done it in a production or development env. I’m also curious how the lifecycle of DBT models works in revision control? Finally, has anyone migrated from couch2pg to CHT Sync?
Thank you for this! I’m very excited about DevOps role and have been learning more about this in the past weeks. Of course I’m not an expert but if there’s time during the call, I’d love to discuss a general idea: applying DevOps principles to cht-core:
Component-Based Design - Making individual parts of cht-core independently replaceable.
One Repo per Component - Benefits of separate Git repositories vs. monorepo approach
it is the approach we are using in openIMIS, which is a mirco kernel architecture: the solution is composed of modules that are put together for deployment in a “monolithic” software
Of couse that concern only the main service, we are also using external services like redis, rabbitMQ, PostGres, reverse Proxy, opensearch … deployed as companion docker images
After five year of maintenance:
it simplify // contribution avoiding some of the GIT merge issue
ease innovation because one can create a new module but don’t have to sync with the // development on core
people can customize only one module and taking the shelf version of the others
can be annoying for the CI, module test can pass but migh break integration test
deployment, solution building, release must be scripted (we have 60 + modules): it may create single point of failure but those scripts require mastery of different techno (github, docker, shell, sys admin … )
the monolithic solution/docker image remains easy to deploy
Git maintenance is more complex because the is PR on many repos, it also mean that repo right management need to be inherited from organization or people will keep complaining about access
Thank you so much for sharing your experience with microkernel architecture in openIMIS!
I’m particularly interested in how you manage the balance between modular development and integration. The benefits you highlighted around contributions are exactly what we were hoping to explore for cht-core.
Also, challenges you mentioned around CI, deployment complexity, and Git maintenance are important considerations too. I’m curious - how do you handle versioning across all those 60+ modules? And have you found any specific strategies that work well for ensuring integration tests catch issues that individual module tests might miss?
Your insights after five years of maintenance are incredibly valuable. I hope we can continue this conversations.
Versioning approach is still not good enough, the issue is how to detect patch form minor from major in a automatic way
So far I am pushing for Conventional commit, hoping that major version could be trigger if a commit include breaking changes
for patch and minor, the boundary is also difficult, you could say that official release generate minor but does it really make sense if just a detail is changed; Ideally I would love to have AI for that
regarding the CI we have 2 pipelines executed at each PR : Module test and Full test;
to help gauge prioritization…)