Below is the process used for creating and publishing a release of OpenLMIS 3.x. These steps are being documented for 3.0 Beta, and this page should be used and updated for 3.0, 3.1, and subsequent 3.x releases.
Goals
What's the purpose of publishing a release? It gives us a specific version of the software for the community to test drive and review. Beta releases will be deployed with demo data to the UAT site (uat.openlmis.org). That will be a public, visible URL that will stay the same while stakeholders test drive it. It will also have demo data and will not be automatically wiped and updated each time a new Git commit is made.
Prerequisites
Before you tag and publish the release, make sure the following are in place:
...
Steps
When you are ready to create and publish a release (Note that version modifiers should not be used in these steps - e.g. SNAPSHOT):
...
- Update the serviceVersion of GitHub's openlmis-service-util
- Check Jenkins built it successfully
- At Nexus Repository Manager, login and navigate to Staging Repositories. In the list scroll till you find orgopenlmis-NNNN. This is the staged release.
- Close the repository, if this succeeds, release it. More information.
- Wait 1-2 hours for the released artifact to be available on Maven Central. Search here to check: https://search.maven.org/
- In each OpenLMIS Service's build.gradle, update the dependency version of the library to point to the released version of the library (e.g. drop 'SNAPSHOT')
...
- Do we need a release branch? For the 3.0 Beta release, we do not need a release branch, only a tag. If there are any later fixes we need to apply to the 3.0 Beta, we would issue a new beta release (eg, 3.0 Beta R1) to publish additional, specific fixes.
- Do we need a code freeze? We do not need a "code freeze" process. We will add the tag in Git, and everyone can keep committing further work on master as usual. Updates to master will be automatically built and deployed at the Test site (test.openlmis.org), but not the UAT site (uat.openlmis.org).
- Confirm that your release tags appear in GitHub and in Docker Hub.
- Look under the Releases tab of each repository, eg https://github.com/OpenLMIS/openlmis-requisition/releases.
- Look under Tags in each Docker Hub repository. e.g. https://hub.docker.com/r/openlmis/requisition/tags/ . You'll need to wait for the Jenkins jobs to complete and be succesfull so give this a few minutes.
Note: After tagging each service, you may also want to change the serviceVersion again so that future commits are tagged on Docker Hub with a different tag. For example, after releasing '3.1.0' you may want to change the serviceVersion to '3.2.0-SNAPSHOT'.
...
- For each of the services deployed as a the new version on DockerHub, update the version in the docker-compose.yml file to the version you're releasing. See the lines under "services:" → serviceName → "image: openlmis/requisition-refui:3.0.0-beta-SNAPSHOT" and change that last part to the new version tag for each service.
- Commit this change and tag the openlmis-ref-distro repo with the release being made.
...
- For each of the services deployed as a the new version on DockerHub, update the version in the docker-compose.yml file to the version you're releasing.
- Commit this change. (You do not need to tag this repo because it is only used by Jenkins, not external users.)
...
- Wait about 1 minute between starting each job
- Confirm UAT has the deployed service. e.g. for the auth service: http://uat.openlmis.org/auth check that the version is the one chosen.
...
Once all these steps are completed and verified, the release process is complete. At this point you can conduct communication tasks such as sharing the URL and Release Announcement to stakeholders. Congratulations!Moved into Developer Docs: http://docs.openlmis.org/en/latest/conventions/versioningReleasing.html#rolling-a-release