If we have OpenMRS dependencies, need to release the snapshot versions and then upgrade them in Bahmni Distro.
Find the current versions of the dependencies here
In some cases, if we are dependent on SNAPSHOTs, make sure that other release branches are not deploying snapshots with the same snapshot versions.
Branching/Tagging
Ensure all repositories are appropriately tagged/branched, feature branches merged, all artefacts pushed to repositories (e.g. npm registry), all dependencies (like dependent libraries) reflected appropriately.
Jira cards must reflect such tasks clearly.
Ensure that all artefacts are traceable for a particular build - usually done in CI/CD
As of now, for many repositories (like bahmnniapps, bahmni core etc), we usually branch out before release, i.e when all the dev work is done and before the QA process starts. The release version refers to the name of the branch that we going to create (eg: release-0.91). Once the branching is done we will not be doing active development on that branch, only the fixes which are found as part of QA process will go into the branch (and also to master).
All other active development changes (usually for cards that for next releases) have to go into master/feature branch.
TODO: Verify that the branching scripts are updated. Update documentation for npm, and other libraries pushed to public repositories (for nexus)
Identify and if required spin environments for release.
Spinning new environments and using them ongoing basis cost money.
Spinning new on-demand and destroying them post task may be alright, but we should have an indicative costs.
Any new instance spinning (permanently) should be notified to infrastructure[at]bahmni[dot]org
Notify core-team and community of any QA environment changes. For example - if an existing QA environments will now reflect master or to-be-released version
Older pipelines
` So the oldest pipeline can be archived/deleted.
Since we have limited resources (AWS instances), we usually pause the oldest version pipelines and allocate it to master (next release)
The oldest version pipeline is paused, and if needed to be activated then admins need to reallocate environments.
After the release of latest version, we should take backup and usually remove Current-3 pipeline config from CI/CD.
Working through the release
Kick off
Discussion in PAT calls about release process, communicate through talk channel for updates to community
discuss late must-have inclusions
discuss late exclusion - issues/cards, that can not be part of this release.
Identify releases - alpha, beta etc. Decide indicative timeframes
The contents would be going to the release notes sections not the document.
Its also good to start a "Petty Checklist" - for smaller tasks that are important and must be done (those which may not find a place in JIRA).
Keep JIRA board updated and in control
All issues during the QA process must be logged in JIRA.
Use PAT calls for decisions like exclusion an issue to next release, inclusion of any issue
Ensure that all issues part of the release (marked with the appropriate fix version/s) are reflected appropriately in terms of resolution (Ready for testing/ QA done) on the Jira Board.
Ensure and verify cards marked with "need-doc-update" are reviewed for documentation - for narration, organisation, completeness, clarity
Releasing artefacts
Release mediums
Bahmni Repo on AWS s3 is used development/QA purposes and also for alpha and beta releases.
JFrog Bintray is used for any final public releases.
Within the Pipeline Group, usually there would be specific pipelines for each component, library, usually also marked with release number. For example - Bahmni_MRS_v0_91, Bahmni_Reports_v0_91 etc
You may get individual artefacts directly from the CD pipeline stages. (Usually a faster way to get specific artefact to test in your dev environment) - for example: run history of Bahmni MRS 0.91
Compilation, Integration, Testing, Packaging etc for each components are automated.
Functional tests for Bahmni Connect (Android APK build) must be run in developer environments.
They are not run through CI/CD anymore (Genymotion AMI costs!).
Some of the functional test stages of a particular components are triggered manually and on-demand. for example - "Function Stage of Bahmni MRS".
Deployment to QA environment is triggered manually, admins/core-team have privilege to do that.
Pipeline group "Deploy" - has multiple environment specific pipelines for releases.
Artefacts are published through the "Bahmni_artifacts_v[number]" pipeline of the release pipeline group. Only admins can do that.
Final releases are done by admin from pipeline "release to public" under the release pipeline group.
Hashicorp provides tools like vagrant and packer. For Bahmni, we use packer to build Bahmni virtualbox and host it in https://www.vagrantup.com/
We don’t have a pipeline to build the Vagrant box and push to Atlas. Follow the wiki page on how to build the box. Admins need to push to Hashicorp.
TODO: Wasn't there a script? Verify
Deployment in demo environments
Once the latest version is available for release, provision or take update on public demo environments - demo’s environments (demo.mybahmni.org and demo-us.mybahmni.org) and for TB demo (demo-tb.mybahmni.org). Admins and select members of core team having env access can do that.
These environments are outside the defined networks in Bahmni AWS CI/CD realm. We need to manually deploy.
Sanity check to verify that demo environment is working after the deployment.
Documentation
Bahmni wiki at Atlasssian for documentation of all features.
Documentation is part of the JIRA cards. In case they are not, they should be done before the release notification to public.
Verify new features and enhancements in the corresponding release has documentation updated on Bahmni Wiki pages.
Ensure relevant documentation is marked with applicable version.
Ensure feature videos & highlights of the release are uploaded to Bahmni Community Channel on youtube.
Only people with the credentials of Bahmni Youtube Channel can do this.
Update release notes, and prerequisite steps for the installer to work
Release notes should be in the format as in this page. It must mention the features, enhancements, bug fixes, Known Issues and the installation prerequisites for the corresponding release.
As explained before, it helps to collaborate on a google doc first for collating the release notes and then upload the final version on the wiki page.
Ensure you update the All Bahmni Releases Page with the RPMs and pipeline details of the latest release.
Share the news - It is now time to announce it to the world about the release!
(We would have given intimation in PAT calls and to Bahmni Coalition)