We are currently looking for a tool that can do auto-deployment of application on every pull request triggered on qaframework module and can support auto deployment of application to the staging environment before promoted to production. A tool that can build independent applications on each pull request, provide a link on the PR page to the deployment while the PR is open.
Why is the tool necessary?
To makes it easier to test proposed changes, as opposed to the current pull and build process developers on the QA team have to go through.
To make it easier get quick feedback on proposed changes, from the product owners and other stakeholders.
Simplify continuous delivery of new changes before sent to production.
Also cut down the length of the feedback loop in regards to proposed improvements to the qaframework.
etc
This tool can be implemented in other OpenMRS modules to simply the delivery processes of our products. Of recent I was looking at a similar tool called Heroku but had limitations concerning with pricing(its not free) and we opt for a tool which is FOSS oriented.
does any one out there knows a suitable tool that can do the work efficiently?
I must admit I admire the way you do research to ensure the community has best. I can’t wait to see how the new tool will function different from the current tool. @kdaud did you forget to mention the FOSS oriented tool you narrowed down to? This will help members to have a good comparison between the current tool and the one you are suggesting in terms of the benefits and limitations before making a decision to switch or not.
We generally use Bamboo jobs for deployment issues and especially promotion. We generally don’t do deployments on a per-PR basis, as we don’t have the infrastructure capacity for that. However, the RefApp 2.X tests already spin up a Dockerised instance of OpenMRS for each test.
All that said, it’s a little unclear to me what you want to have happen. Would you mind spelling things out a bit more?
Yes, I understand that overall workflow and we support something like that through Bamboo (albeit not on a per-PR basis, but on a per-merge basis). I guess what I’m struggling with here is what, exactly, would be deployed?
@ibacher what is currently deployed on merging is exactly what we would like to be deployed before merging, but with the unmerged pull request changes.
Well, this is sound so intresting @kdaud thanks for bringing this up, i think sonaqube integration with github can also help in auto deployment of application, Good news is that it was recently integrated in core.
This should not be too complicated to achieve. It may not come down to a single tool but rather a combination of tools but at the core of it you would have to use containers. I have helped implement similar setups for various organizations including @AMPATH for their POC
From my experience this setup is really helpful when you are rapidly iterating and adding new features it allows your user testing teams , peers and stakeholders to start testing out new features as soon as the first PR is available without waiting for the code to be merged and deployed to some sort of integration environment.
I have seen cases where after the initial PR it becomes very clear that the feature will fail acceptance testing and expectations have to be set early on in the development.
Another advantage is that the code is always rebased against the main branch which is running in production and then deployed in isolation providing a chance to catch any regressions that may be introduced by your work.
At @AMPATH we achieved this using a custom node application receiving callbacks from github and triggering a process to setup a deployment with the code at the tip of the PR. I have also used gitops with argocd to achieve a similar outcome this of course needs Kubernetes and is a whole different take on delivering software to production.
All this comes at cost in terms of effort and money we will have to weigh against the benefits of being able to test fully isolated builds of each PR.
(Side note : I used containers not docker it would be nice for the community to start making this distinction as we move more and more towards the cloud some other container engines include cri-o and containerd, infact if your ever run a workload on Kubernetes you won’t be using docker at all.)
The ideal situation would be a complete a complete OpenMRS stack with sample data. This way you can always be sure to test your feature in a clean setup.
Hi @kdaudHeroku: is a Cloud Application Platform that happens to have a whole ecosystem of tools to support the building and deployment of code from git(source control) / local dev environment to the cloud.
The correct tool to use for your CI/CD automation may depend on the environment that you intend to set up. As there is a mass exodus towards Cloud Native applications built around Kubernetes, most solutions may require a very specific environment.
If you intend on using Kubernetes look no further than Jenkins X. It has built-in support for pull request-based development with support for previews. There is also support for different environments like DEV, STAGING, and PRODUCTION as well as fine-grained Access Control.
Otherwise, the good old Jenkins can be of great use if you do not intend on using Kubernetes and you are okay with the DIY approach and use of plugins.
