BBahmni 한국어 매뉴얼검색홈
한국어 번역 완료
한국어English

Release Process

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관련 문서: JIRA
  • Community should have been intimated well in advance of development freeze date관련 문서: Release 0.91Release 0.92
  • 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)관련 문서: mvnrepo.openmrs.org
  • ict4h libraries and modules are available at oss.sontype.org관련 문서: repo.mybahmni.org
관련 문서: 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 
관련 문서: here
  • 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.
  • See also branching관련 문서: 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/CDBackup and version control CD config 
  • Define new pipelines and environmentsRefer: Steps to be done in CI/CD
  • see also: BranchingTODO: Verify that the branching scripts are updated. Update documentation for npm, and other libraries pushed to public repositories (for nexus)  
관련 문서: BranchingBranching
  • 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
  • ` 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 offDiscussion in PAT calls about release process, communicate through talk channel for updates to communitydiscuss late must-have inclusions 
  • discuss late exclusion - issues/cards, that can not be part of this release. 
  • Usually we will go through alpha, beta, release candidate releases. Clearly communicate about the releases, environments in community 
  • See example for 0.91
  • The contents would be going to the release notes sections not the document. 
  • Keep JIRA board updated and in control 
  1. 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 
  2. 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.
  3. Ensure and verify cards marked with "need-doc-update" are reviewed for documentation - for narration, organisation, completeness, clarity  
  • Releasing artefactsRelease mediumsBahmni 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.
관련 문서: Bahmni Repo on AWS s3JFrog Bintray
  • All releases must be done through CI/CD ServerAnyone 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 PipelinesFor 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
관련 문서: Bahmni_Pipeline_Group_Release_0_91S3 artifactoryBahmni MRS 0.91
  • 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!). 
  • Pipeline group "Deploy" -  has multiple environment specific pipelines for releases. 
  • Verify uploaded artefact integrity. Check the MD5 checksums. 
  • With the final artefacts from bintray, verify installation and upgrade. 

Going Public

  • Public ReleaseWe publish bahmni artifacts which are stable and released versions to bintray.
  • Triggered by Admins through the "Release_to_public_[version]"  pipeline. 관련 문서: bintray
  • 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관련 문서: Hashicorphttps://www.vagrantup.com/
관련 문서: Build Bahmni Vagrant Box using Packer
  • Deployment in demo environmentsOnce 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.
관련 문서: demo.mybahmni.orgdemo-us.mybahmni.orgdemo-tb.mybahmni.org
  • 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.  관련 문서: Bahmni Wiki
  • Only people with the credentials of Bahmni Youtube Channel can do this.
  • 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.  
  • 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
  • On openMRS talk
  • Slack channels like #community
  • Winding upDelete 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
원문 정보

Bahmni Wiki · CC BY-SA 4.0

원문 보기 ↗