What things could we be doing within the OpenMRS Development Community to improve our CI processes? Who should be doing them? What features would be most helpful? What would simply be nice to have?
Whether you have been involved with creating CI plans for OpenMRS, you’re a module developer whose never touched ci.openmrs.org but have some suggestions, or you’ve been involved with other projects and have some experience with approaches to CI that worked well and the OpenMRS Community would do well to imitate, we’d love to hear from you!
Our plan is to consolidate feedback & ideas and then use them to define a strategy for moving CI forward. Please reply here in Talk or add to or revise the shared brainstorming google doc below.
[quote=Background]During the last 15 minutes of this week’s Dev Forum on Platform 2.0, we discussed the state of CI Management for OpenMRS. We reflected on the great progress we’ve made in CI, how we’ve relied (perhaps too much) on the great contributions from @cintiadr, and how we might be able to take our CI efforts to the next level. At the end of that discussion, we asked whether we should schedule some dev forum time to discuss further. I suggested that we might be better off brainstorming and consolidating idea/suggestions/concerns asynchronously with a Talk post ± a shared Google doc. So, here we are… Google doc below.
I do have the docker builds almost working, but I need help to get the
application up. The next thing I wanted to handle was the terrible position
of snapshot dependencies, how to untangle that. Well, that’s not really
testing strategy nor pipeline, but that’s the plan.
What about using Jenkins  the famous open source automation server?
Only the initial required server-side configurations is needed to be done by some one. Most of the times, just one person can take the responsibility to oversee the progress. In-fact the build failures, test failures can be automated to notice for required or responsible people. It gives a informative report every time it builds the product. It will non-stoppingly keep building all the products that is automated in the queue.
This can be included in the patch making process also. The jars built by the Jenkins server can be given as the patch after the build is success. This will give additional transparency and confirmation of correctness for the patch.
Thought for a quick reply as I have to go. Will do research on these two and explain ASAP.
Well, first of all Jenkins is fully free and opensource Which is the greatest concern for me. But for us Bamboo is also free as I know.
Both have their own up and downs. But I believe jenkins is more flexible. You can find many plugins for that. They keep building more plugins and they are free and open source.
It is true from the usability point of view, bamboo is better than jenkins. But from the view of extensibility and adaptability as an opensource community Jenkins is better.
But considering the fact, that bamboo is already integrated, we should do more research on why many of other opensource projects had moved from bamboo to jenkins in the past. Because we should not move unless there is a proper reason.
I think one main question we have to ask is are we using a considerable amount of Bamboo functionality. Can you point out to a document on Bamboo usage in openmrs.
Another question is what are the other Atlassian product we use other than Jira and Bamboo.
@ttcphilips I wouldn’t spend too much time researching this.
We are using the whole Atlassian suite of tools (Confluence for wiki, and JIRA for issues), and we have a significant amount of configuration already done in Bamboo. So it would take significant advantages to make it worthwhile to move off of Bamboo. If we were actually entertaining the notion of moving from Bamboo, I would be more interested in newer generation products (e.g. ThoughtWorks produces Go CD, which more natively supports continuous deployment ideas).
But for today Bamboo is serving us well, and our bottlenecks are a lack of people dedicating time to CI. So, let’s bring this back to @burke’s original post: what are specific improvements we can make to our CI processes?
Personally I think these small-ish things could help a lot:
automatically deploy modules to modules.openmrs.org as part of releasing a module from CI (could be scripted via maven, via bamboo, or by having modulus watch github)
automate more of the module release process, e.g. tie together doing a release in both Bamboo and JIRA, and create an automatic release notes page on the wiki.
automate much more of the platform release process (as has already been done for the reference application module release process)
Highly agree with @darius. I am just a newbie trying to push my limits. So still getting to know things.
I think it would be better to create a web application as a tool for releasing process. We may improve existing application to be able to specify the following things in order to automate more of the module release process.
JIRA tickets - If we have separate public JIRA and internal or support JIRA both can be specified
SVN commit and/or Git commit hash
Specify the time taken to complete the tasks
Specify the people involved (In developing and QA)
Test commits and information
Other information that is needed for the release notes can also taken from this form.
Then we can organize the app such that test (new tests for the new improvement) are mandatory or should be approved by an administrator when tests are not available for the task. This way the robustness of the system will be assured. Then releas notes will be updated. After that we can trigger a script to deploy modules via bamboo. Then the JIRAs can be automatically updated.
This is just the simple workflow I thought about. Surely we can integrate the suggestions from this brainstorming session. Maybe this can be improved to a Gsoc project this year.