릴리스 절차
개발 동결`
- 사전 요구 사항: 모든 카드에 JIRA의 "fixVersion"과 "Sprint"가 지정되어야 합니다. 릴리스의 모든 카드는 쉽게 식별할 수 있어야 합니다. 일반적으로 Release 0.91, Release 0.92처럼 영구 링크가 있는 보드를 정의합니다. 개발 동결 날짜를 커뮤니티에 충분히 미리 알려야 합니다.
- 의존성의 OMOD를 확인된 릴리스 버전으로 업그레이드합니다. OMOD 릴리스 버전을 만든 뒤 업그레이드합니다. OpenMRS 모듈(OMOD)은 mvnrepo.openmrs.org에 릴리스합니다. Bahmni 전용 모듈(OMOD)은 repo.mybahmni.org(S3)에 릴리스합니다. ict4h 라이브러리와 모듈은 oss.sontype.org에서 제공합니다.
- OpenMRS 모듈: openmrs, operation theater, bedmanagement, reporting, webservices rest, reportingrest, idgen, owa, atomfeedmodule 저장소. OpenMRS 의존성이 있다면 스냅숏 버전을 릴리스한 뒤 Bahmni Distro에서 업그레이드해야 합니다. 현재 의존성 버전은 관련 페이지에서 확인합니다.
- 브랜치/태그: 모든 저장소에 적절한 태그나 브랜치를 만들고, 기능 브랜치를 병합하며, 모든 산출물을 저장소(예: npm registry)에 게시하고, 종속 라이브러리 같은 모든 의존성을 올바르게 반영합니다. JIRA 카드에 이러한 작업을 명확히 기록해야 합니다.
- 브랜치 관련 문서도 참조하십시오. TODO: 위 링크에는 모든 외부 모듈이 나열되어 있지 않으므로 위키를 업데이트해야 합니다.
- CI/CD에서 최신 브랜치의 파이프라인을 만듭니다. CD 구성을 백업하고 버전 관리합니다. 새 파이프라인과 환경을 정의합니다. CI/CD 절차 및 브랜치 문서를 참조하십시오. TODO: 브랜치 스크립트가 업데이트되었는지 확인합니다. npm 및 공개 저장소(Nexus)에 게시하는 기타 라이브러리 문서를 업데이트합니다.
- 새 환경을 만들고 계속 유지하면 비용이 발생합니다. 필요할 때 새 환경을 만들고 작업 후 삭제하는 것은 괜찮지만 예상 비용을 파악해야 합니다. 영구적으로 새 인스턴스를 만들 때는 infrastructure[at]bahmni[dot]org에 알려야 합니다.
- ` 가장 오래된 파이프라인을 보관하거나 삭제할 수 있습니다. AWS 인스턴스 자원이 제한되어 있으므로 보통 가장 오래된 버전의 파이프라인을 일시 중지하고 master(다음 릴리스)에 할당합니다. 다시 활성화하려면 관리자가 환경을 재할당해야 합니다. 최신 버전을 릴리스한 후 백업하고 일반적으로 CI/CD에서 Current-3 파이프라인 구성을 제거합니다.
릴리스 진행
- 착수: PAT 통화에서 릴리스 절차를 논의하고 Talk 채널을 통해 커뮤니티에 진행 상황을 알립니다. 늦게 포함해야 할 필수 항목과 이번 릴리스에 포함할 수 없어 제외할 이슈/카드를 논의합니다.
- 일반적으로 alpha, beta, release candidate 단계를 거칩니다. 릴리스와 환경을 커뮤니티에 명확히 알립니다.
- 0.91 예시를 참조하십시오. 내용은 문서가 아니라 릴리스 노트 영역에 들어갑니다.
- JIRA 보드를 최신 상태로 통제하며 유지합니다.
- QA 중 발생하는 모든 이슈를 JIRA에 기록해야 합니다. 이슈를 다음 릴리스로 제외하거나 새 이슈를 포함하는 결정에는 PAT 통화를 사용합니다. 릴리스에 포함된 모든 이슈(적절한 fix version 지정)가 JIRA 보드에서 해결 상태(Ready for testing/QA done)에 맞게 반영되었는지 확인합니다. "need-doc-update" 카드의 문서가 서술, 구성, 완전성, 명확성 측면에서 검토되었는지 확인합니다.
- 산출물 릴리스 및 배포 매체: AWS S3의 Bahmni Repo는 개발/QA와 alpha 및 beta 릴리스에 사용합니다. JFrog Bintray는 최종 공개 릴리스에 사용합니다.
- 모든 릴리스는 CI/CD 서버를 통해 수행해야 합니다. GitHub 계정이 있으면 누구나 서버를 볼 수 있고 CI 로그인 페이지에는 guest 계정도 있습니다. 관리자와 커밋 권한이 있는 core-dev 팀은 릴리스 파이프라인 실행 권한을 가집니다. 각 릴리스에는 릴리스 번호가 명확히 표시된 Pipeline Group이 있습니다. 일반적인 이름: Bahmni_Pipeline_Group_Release_[number], 예: Bahmni_Pipeline_Group_Release_0_91. 그룹 안에는 각 구성 요소와 라이브러리별 파이프라인이 있으며 보통 릴리스 번호가 표시됩니다. 예: Bahmni_MRS_v0_91, Bahmni_Reports_v0_91. snapshot OMOD는 S3 Artifactory에 배포합니다. 개발 환경에서 특정 산출물을 빠르게 테스트하려면 CD 파이프라인 단계에서 개별 산출물을 직접 받을 수 있습니다. 예: Bahmni MRS 0.91 실행 이력.
- Bahmni Connect(Android APK 빌드)의 기능 테스트는 개발자 환경에서 실행해야 합니다. Genymotion AMI 비용 때문에 더 이상 CI/CD에서는 실행하지 않습니다.
- Pipeline Group "Deploy"에는 릴리스용 환경별 파이프라인이 여러 개 있습니다.
- 업로드한 산출물의 무결성을 확인하고 MD5 체크섬을 검사합니다. Bintray의 최종 산출물로 설치와 업그레이드를 검증합니다.
공개
- 공개 릴리스: 안정적인 릴리스 버전의 Bahmni 산출물을 Bintray에 게시합니다. 관리자가 "Release_to_public_[version]" 파이프라인으로 실행합니다. 업데이트된 Bahmni 개발자 VM을 Atlas에 게시합니다. HashiCorp는 Vagrant와 Packer 같은 도구를 제공합니다. Bahmni에서는 Packer로 Bahmni VirtualBox를 만들고 https://www.vagrantup.com/에서 호스팅합니다. Vagrant 박스를 빌드하여 Atlas로 게시하는 파이프라인은 없습니다. 박스 빌드 방법 위키를 따르고 관리자가 HashiCorp에 게시해야 합니다. TODO: 스크립트가 있었는지 확인합니다.
- 데모 환경 배포: 최신 버전이 릴리스 가능해지면 공개 데모 환경 demo.mybahmni.org, demo-us.mybahmni.org 및 TB 데모 demo-tb.mybahmni.org를 프로비저닝하거나 업데이트합니다. 환경 접근 권한이 있는 관리자와 일부 핵심 팀원이 수행합니다. 이 환경들은 Bahmni AWS CI/CD 영역의 정의된 네트워크 밖에 있으므로 수동 배포가 필요합니다.
- 모든 기능의 문서는 Atlassian Bahmni 위키에 둡니다. 문서 작업은 JIRA 카드의 일부입니다. 누락되었다면 공개 릴리스 공지 전에 완료해야 합니다. 해당 릴리스의 새 기능과 개선 사항에 맞게 Bahmni Wiki 문서가 업데이트되었는지 확인하고 관련 문서에 적용 버전을 표시합니다.
- Bahmni YouTube 채널 자격 증명이 있는 사람만 이 작업을 할 수 있습니다.
- 릴리스 노트는 해당 페이지의 형식을 따라야 합니다. 기능, 개선 사항, 버그 수정, 알려진 문제 및 해당 릴리스의 설치 사전 요구 사항을 포함해야 합니다. 릴리스 노트를 모으기 위해 먼저 Google 문서에서 협업한 다음 최종 버전을 위키에 올리는 것이 좋습니다.
- 소식 공유: 이제 릴리스를 전 세계에 알립니다. PAT 통화와 Bahmni Coalition에는 미리 알렸을 것입니다. 커뮤니티 포럼, OpenMRS Talk 및 #community 같은 Slack 채널에 소식을 공유합니다.
- 마무리: 가장 오래된 릴리스(Current-3)의 파이프라인을 삭제합니다. 먼저 CI/CD 구성을 백업합니다. JIRA에서 릴리스를 종료하고 핵심 팀 및 커뮤니티 리더와 회고합니다.
원문 정보
원문 보기 ↗Bahmni Wiki · CC BY-SA 4.0