Development freeze`

Pre-requisites
- All cards should have been marked for "fixVersion" and "Sprint" in JIRA
- All cards for a release must be easily identifiable. Usually, we have a board defined, which have a parmalink. e.g Release 0.91, Release 0.92
- Community should have been intimated well in advance of development freeze date

Upgrade to identified released version of omods in dependencies. Release version of omods and upgrade.
- OpenMRS modules (omods) are released to mvnrepo.openmrs.org
- Bahmni specific modules (omods) are done to repo.mybahmni.org (s3)
- ict4h libraries and modules are available at oss.sontype.org

OpenMRS modules: openmrs, operation theater, bedmanagement, reporting, webservices rest, reportingrest, idgen, owa, atomfeed
module repositories:
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.

See also branching

TODO: The above link does not list out all the external modules. We should update the wiki.

Create pipelines for the latest branch in CI/CD
- Backup and version control CD config
- Define new pipelines and environments
  - Refer: Steps to be done in CI/CD
  - see also: Branching
    - 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
- Identify owners - overall release owner(s), individual module/artefact release owners, CI/CD admins, environment owners/accessors etc
- Communicate about QA environments
  - Usually we will go through alpha, beta, release candidate releases. Clearly communicate about the releases, environments in community
- Identify and seek help for QA - project teams, bug bashes, feature testing by groups/individual, contributions
- Use daily-standups to continuous prioritisation.
- Provide regular updates in PAT calls, talk
- Start a working release document, and collaborate through the release process
  - See example for 0.91
  - 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.
- All releases must be done through CI/CD Server
  - Anyone with github account can view the server. CI login page also has a guest account.
  - Admins, core-dev team (those having commit rights) have privilege to release pipelines.
  - Release Pipelines
    - For each release there would be a Pipeline Group defined which will be clearly marked with release number.
      - usually in naming format: Bahmni_Pipeline_Group_Release_[number] e.g. Bahmni_Pipeline_Group_Release_0_91
      - 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
        snapshot omods - are deployed to S3 artifactory.
        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.
      - Example: Release_To_Public_v0_90
    - We need to manually upload the apk file for bahmni-connect to bintray under https://dl.bintray.com/bahmni/generic/ path. Admins can do that.
  - Verifying binaries and install/upgrade
    - Verify uploaded artefact integrity. Check the MD5 checksums.
    - With the final artefacts from bintray, verify installation and upgrade.

Going Public

Public Release
- We publish bahmni artifacts which are stable and released versions to bintray.
- Triggered by Admins through the "Release_to_public_[version]" pipeline.
- Publish updated Bahmni developer VM to Atlas.
  - 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
- 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)
- Share the news on Community forums
- Post it on social media(twitter), Facebook, Medium Blog
- Email infrastructure[at]bahmni[dot]org, email specific implementations if required, email/tag networks/well wishers

Winding up
- Delete the pipelines for the oldest release. i.e Current-3. Backup CI/CD config first.
- Close release in JIRA
- Retrospective with core team, community leads

On this page

Release Process

Development freeze`

Working through the release

Going Public