We’d like to make the release processes much easier. The ultimate goal is to be able to release a platform or RA in one step + book keeping in JIRA and announcements. Here are the things I suggest we change in the first pass:
Merge two CI plans for releasing platform and creating platform standalone into one.
Merge two CI plans for releasing RA and creating RA standalone into one.
Deploy platform, RA and standalones to maven and setup distributing them automatically on Bintray (we will get rid of publishing to sourceforge step).
Create release notes file in platform and RA project repos so that it can be automatically pushed to https://wiki.openmrs.org/display/RES/Releases and a new page created when releasing from CI.
Only those 4 steps should cut the number of release steps at least by half.
I think this is a great idea, and I strongly approve of spending time on this.
A few questions/thoughts:
I assume that releasing the platform would still mean releasing one of the OpenMRS Core builds, followed by one more CI plan (which releases platform and platform standalone). Right?
Note that our Platform Release Process differs for Alpha, Beta, RC, Final, and Maintenance. Maybe the only difference is in the communication and level of testing required, but the release scripts may need to reflect some differences.
I would recommend that we avoid “programming” the scripts in bamboo, but instead we write several independent scripts that do the various steps of the process, and can be run via docker or vagrant (to ensure a known environment). We should still have a CI plan to run these, but in case things turn out to be brittle and CI fails, someone can also run some of the steps locally.
that said, there will be a bunch of credentials required to do this, so maybe it’s not feasible to run outside of CI anyway
the main point is that we should expect the process to be a bit brittle, and so our scripts should be tolerant, and able to pick up and complete a partially-successful release
Maybe use Gradle for this.
We can still do checks for some of the manual steps, e.g. “Verify that there are no unreviewed open tickets against the version to be released” is something we can test with a REST call.
It would be nice to autogenerate some additional artifacts that we’re not currently generating:
list of contributors (from reading the git history)
@raff I only the other hand have only released twice using the Maven build scripts not Bamboo or CI. Some pains here:
After releasing the platform, then building standalone requires editing the platform version before building. Is it possible to have a distro.properties file for core which is updated with the latest version of core automatically and the Rest Web services so that standalone is now built using SDK without need to edit files.
Given #1 above can standalone automatically be built when core is released - so that this step is not needed anymore
There is a Groovy script that @burke developed for the data model changes, this could also be automated between the platform version and run automatically on release.
Getting read of SourceForge uploads is very welcome
Yes, it’s to allow modules included in the platform to depend on openmrs-core. @ssmusoke, it’s why we need to keep core and standalone (platform) build separated.
I completely agree scripts need to be fault tolerant and manually runable, if needed.
I’d rather avoid introducing a new build tool if possible (unless it turns out to be too complex for maven).
FYI I wrote some code that could read a git history and generate a list of contributors for ref app I think during the release of 2.2, I can convert it into a maven plugin that we could integrate into the maven build cycle and activate it when releasing. The issue I recall is that github limits you on how many request you can make to the rest API in an hour, so this would require pointing the tool to a local git clone that maven is using to build and release.
