On improving testing upgrades for releases

Development
1

Continuing the discussion from 1.11.4 upgrade fails due to person change to datetime:

A response to a comment from @wyclif in the JIRA issue:

I thought one of the TODOs of a release manager is to test that they can install the release and that they can upgrade from an existing demo dataset in order to catch such bugs.

In the wiki page at Release Process - Documentation - OpenMRS Wiki we see the following advisement at the top of the page, but it’s the only place upgrades are mentioned for any type of release:

We recommend trying upgrading from various previous releases to your release mainly for the major release so that if there are any issues, they can be dealt with before the release.

So it sounds like this might need to be:

  • More explicit in its instructions to release managers, and
  • Listed in the checklist for each type of release.

I would defer also to our rising “Release Management Manager” @maurya to see if he has any thoughts.

2

Beyond manual testing, I feel that we should have a CI setup that tests installs and upgrades. Logging time would be great on the large dataset, as has been a problem in the past. So that people can estimate the downtime with upgrades. We’ve seen that for a number of things like the MariaDB or PostgreSQL compatibility such a CI plan will be very useful. So beyond formalizing what the release manager needs to test, the automated test in a CI should be our approach

3

+1 to @sunbiz and @burke’s request to test this via CI.

This particular case is interesting because it specifically fails when you do the upgrade from the UI so I can easily envision us having missed it through automation.

My first thought is that we do two things. For each supported release branch of openmrs-core (e.g. currently 1.9.x, 1.10.x, 1.11.x), we have two CI plans:

  1. The first (a) installs the oldest version of OpenMRS in a supported release branch (currently 1.9.0), and (b) upgrades it to the head of the release branch of openmrs-core
  2. The second installs the prior release version, and upgrades to the head of its release line (e.g. from the released 1.9.9 to head of 1.9.x)
1 Like
4

Actually the documentation is technically correct to say to test the upgrade for the major release because by convention there should be no database changes in minor releases, but in this case there was.