Wiki Spaces

Documentation
Projects
Resources

Get Help from Others

Q&A: Ask OpenMRS
Discussion: OpenMRS Talk
Real-Time: IRC Chat | Slack

Documentation

Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
  •  
Pro- TIP: READ COMPLETELY before you close this even though the steps have to be done one 'after' the other read everything at once in the start. 
That means, go through each point to make sure that at a later stage you should not have plenty clarification's.

 

OpenMRS 2.x releases are different than OpenMRS platform releases (like 1.11.x). 
Platform releases usually consist of alpha, beta releases and have Sprints to complete tickets in a short span of time. OpenMRS 2.x is a collection of modules and hence its release consists of releasing all the modules planned to be included in the 2.x release and testing if all of them function collectively.
The release manager needs access to these accounts:
  1. OpenMRS ID: This is the basic account that you create when associating with OpenMRS.
  2. CIEL dictionary dropbox account:  This account is updated with the latest CIEL dictionary and each OpenMRS 2.x release includes the latest released CIEL dictionary.
    Andrew Kanter manages the account and you would need to mail him  requesting the access for the account. CIEL dictionary is an SQL dump file.
  3. mdsbuilder: It is an OpenMRS server and you would need access to the server, an account in the OpenMRS account and also the mysql openmrs_user/root credentials, please create a new case requesting these accounts at OpenMRS helpdesk . For requesting server access you need to have an SSH key pair. (For windows users new to using an SSH key pair for accessing a linux server , this guide might help you create one. You will have to request helpdesk to give access to this SSH key).
  4. SourceForge account: Every release of OpenMRS is hosted here, you would be uploading the released version here. You have to create a SourceForge account and then create a new case at OpenMRS helpdesk requesting your user to be given the rights for OpenMRS account.
  5. OpenMRS.org account: This is not your OpenMRS ID, it is a WordPress account where you will need to create a blog post once you release the OpenMRS version. Create a new case at OpenMRS helpdesk requesting access for the OpenMRS.org account. Help desk will create the account for you.
  6. OpenMRS Maven account: Source Jar files are stored here. Create a new case at OpenMRS helpdesk requesting access for this account. You will need this account to verify if every module and the final release have been uploaded here.
  7. CI Bamboo Account: The actual release takes place here. You will need your access to this account to finally release the version. Create a new case at OpenMRS helpdesk requesting access for this account.
  8. Administrator role in JIRA for Reference Application Project: Request for being an administrator of the Reference Application project in JIRA from a current Administrator - Presently Darius Jazayeri is an administrator for the project.

Release Process:

Begin the process of release management:

  1. Analyse the release stage requirements for the particular release by following  Technical Road Map.
  2. Attend and organize Project Management Meeting and Design Forum to communicate and decide on what needs to be done throughout the release process.
  3. Try to create a release management process to help you and others understand the tasks to be done. This can be done on OpenMRS Talk as done here.
  4. Search for tickets in JIRA that have the release version or having tag as OpenMRS 2.x(The version to be released)  and have them fixed before having that module released.
  5. Make sure that for each module that needs a new version to be released, that the user documentations has been updated to reflect the UI changes if necessary. Note that each release of the reference application has it own user documentation page e.g the one for 2.2 is here
  6. Set an initial deadline to release all the modules scheduled to be included in the release and request each modules owner to release the modules in that time. Excepting the Reference Application, Reference Application distro , Reference Application, reference demo data, reference metadata, all the other module can be released by this time. For the modules already existing in the release bundle check in OpenMRS github account if any new changes have been made after the previous release if don't request the any action just include it in the release management process that it is in a release ready state. If there are changes request the module owners if they would like to release a new version to be included in the new OpenMRS release.
  7.   A module should be released in Maven Nexus , and released in OpenMRS Modules Directory  to be considered released. Please verify that each module has been released properly.

Releasing the CIEL Dictionary:

  1. Update CIEL on the mdsbuilder to the latest version using the sql dump that you download from the CIEL dictionary dropbox account.
    1. Login to mdsbuilder using ssh.
    2. Run mysql import of the sql dump.
  2. Update Metadata Sharing packages to the latest versions of CIEL concepts
    1. Login to mdsbuilder OpenMRS instance.
    2. Go to Administration -> Metadata Sharing -> Export Metadata and choose a package (repeat b. and c. for the following packages: Reference Application Concepts, Reference Application Diagnoses, Reference Application Order Entry and Allergies Concepts)
      1. Click New Version.
      2. Follow the creating package wizard leaving all defaults.
    3. Click Download Latest to get the zip file for that package. 
  3. Export concepts using data exchange to preserve IDs for later updates of CIEL.
    1. Login to mds builder.
    2. Go to System Administration -> Advanced Administration -> Data Exchange Module / Export. Upload header.xml file from all you downloaded in 2. c, this generates an xml data set, copy the contents of the generated files to their respective xml files under https://github.com/openmrs/openmrs-module-referencemetadata/blob/master/api/src/main/resources
    3. Add any missing calls to dataImporter.importData(...) in https://github.com/openmrs/openmrs-module-referencemetadata/blob/master/api/src/main/java/org/openmrs/module/referencemetadata/ReferenceMetadataActivator.java to load all files with the exported concepts.
    4. Set ReferenceMetadataConstants.METADATA_VERSION to a value higher by 1
    5. Remove zip packages containing concepts (if any) from https://github.com/openmrs/openmrs-module-referencemetadata/tree/master/api/src/main/resources and their declarations in https://github.com/openmrs/openmrs-module-referencemetadata/blob/master/api/src/main/resources/packages.xml
    6. Commit and push changes.
    7. Release the Reference Metadata Module with the version matching the release version of OpenMRS 2.x

User Acceptance Testing:

  1. Schedule a time period after the initial release deadline for releasing the modules set under the section Begin the process of release management- 4th point. Even if some modules are not released by this time the testing can begin.
  2. Setup a User Acceptance Testing(UAT) server with the OpenMRS instance having the latest released modules by creating a new case at OpenMRS helpdesk requesting the setup of the server.
  3. Request the Module Owners/Implementers to verify the module's functionality individually.
  4. Organize events to encourage people to participate in testing the new version before it's release.
  5. If the UAT results in discovery of new bugs please file them and after they are fixed , request releasing a new version for the specific module where the issue has been identified.

Final Release Process:

  1. Release all modules to be included in the distribution
    1. Go to https://github.com/openmrs/openmrs-distro-referenceapplication/blob/master/pom.xml and look for SNAPSHOT dependencies
    2. Release all SNAPSHOT dependencies and update their versions in https://github.com/openmrs/openmrs-distro-referenceapplication/blob/master/pom.xml
    3. Release all SNAPSHOT dependencies and update their versions in https://github.com/openmrs/openmrs-distro-referenceapplication/blob/master/ui-tests/pom.xml
    4. Make sure all declared versions of modules are the latest compatible versions
  2. Release the distribution from CI
    1. Go to https://ci.openmrs.org/build/admin/edit/editBuildTasks.action?buildKey=REFAPP-OMODDISTRO-JOB1
    2. Click on Maven 3.x to open the Check module versions task
    3. Make sure that the goal is changed from ${bamboo.checkVersions} to validate
    4. Click Save at the bottom
    5. Click on Run->Run Plan(right side top corner) to create a build with these settings. Please remember the build number. .Create a new case at OpenMRS helpdesk requesting to tag this build as a release.
    6. Check the generated build to make sure that it produced artifacts, which include modules in the declared versions.
    7. Every build stops/pauses at the release stage(you can observe this in the left side column nearing the bottom of the page with section titled Release having a small right-arrow/play symbol beside it).
    8. After verifying the artifacts trigger the release by clicking on the play/right-arrow button next to the Release section located to the left bottom. This begins the process of releasing the OpenMRS 2.x version in maven and packaging the released modules and generating the openmrs-standalone.zip.
    9. Download openmrs-2.x-modules.zip and openmrs-standalone.zip from the artifacts tab in the released build.
      Check if the openmrs-2.x-modules.zip file contains all omod's only.
    10. Once you downloaded release artifacts you can revert the step c

Publishing the artifacts and Announcing the release:

  1. Publishing the Artifacts
    1. Go to - sourceforge.net/projects/openmrs/files/releases/ - log in to your SourceForge account and create a new folder with the release version following the nomenclature of the previous folders. upload the openmrs-2.x-modules.zip and openmrs-standalone.zip downloaded from the artifacts tab in the released build. This might take some time be patient, check and verify that they have been uploaded properly.
  2. Maintain the list of Contributors for the release.
  3. Create the Release notes:
    1. Create a release notes child page in Release Notes with the release version name.
    2. Update the Release Notes page meta tag with the new page you created.
  4. Announcing the Release
    1. Create a blog post in OpenMRS.org announcing the release, it can be similar to the ones created before. Please do not forget to include the list of contributors in the announcement.
    2. Announce the release in OpenMRS Talk similar to the blog post.
    3. .Create a new case at OpenMRS helpdesk requesting to update the OpenMRS.org home page and downloads page to update it to the latest release.
  5. Release in JIRA
    1. Request for being an administrator of the Reference Application project in JIRA from a current Administrator - Presently Darius Jazayeri is an administrator for the project.
    2. Go to this link - https://issues.openmrs.org/plugins/servlet/project-config/RA/versions and enter the date beside the version you are about to release and click on the small settings icon indicating a dropdown that appears when you point the mouse over  the list value for the version and select release.
  6. Update the Release Process wiki with the latest changes if any.