How we use it (I may be overly devops-ey, and I’m also not the closest to this implementation right now) : We break up specific integrations (like for instance a specific health system) into different repositories.
Each integration is in it’s own channel group. Dev Workflow:
a developer works on the dev environment, building his channels and testing it in that environment When he is ready to push it to the higher environments, he runs a ‘mirthsync’ command to pull down the channels from dev, and place them in the local git repo
they make a PR against the dev branch of the repo
After code review it is merged into the repo.
We use a .gitignore in that repository to ensure nothing outside of the channel group is committed.
Each integration repository is versioned separately, with semver (v1.1, v2.4.3) etc.
Each integration repository builds a version artifact from an azure devops pipeline.
it is critically important that no environment specific configs end up in the code at this point. It’s one of the things we need to review in the PR for.
(I Think) we have a separate repository for code templates, that also follow the PR workflow that is also versioned.
There is a top level “integrations-manifest” repository that acts as a list of which integrations at which version to deploy.
This repository is also versioned (ie: integrations-v1.3.0 includes health-system1-v1.2 and health-system2-v3.0) The pipeline on this repository pulls down all the individual listed assets and compiles them into a complete asset for deployment.
On sign-off , it will execute mirthsync to push the directory to the server specified, and deploy the channels. :+1: 1
14:00 the goal here is to allow us to work on integrations separately, while avoiding impact to other integrations. have full traceability of what is deployed to what environment at what time. implement a code review process, so that weird stuff doesn’t get injected into configurations. Give us the ability to roll back to previous releases.
14:01 there’s a bunch of blind spots still. like deleting channels
14:01 configmaps are annoying as there can onlyh be one per mirth instance, you can’t append values to it it just wipes out and replaces them.
i can’t remember where we landed on code templates inside the integration repos, because they share a namespace.