릴리스 하기
릴리스 하기 (Releasing)
HBase의 릴리스 후보(RC)를 만들고, 릴리스를 진행하는 절차를 살펴볼게요. 커밋터만 hbase 아티팩트를 릴리스할 수 있어요. Docker 기반 스크립트와 수동 절차, Maven 배포, svnpubsub 스테이징까지 다뤄요.
출처: 문서
본문
HBase 1.x에 대해 빌드하기 (Building against HBase 1.x)
HBase 1.x 빌드 방법은 옛 refguides를 참고해 주세요. 아래 내용은 hbase2 빌드에 대한 것이에요.
릴리스 후보 만들기 (Making a Release Candidate)
커밋터만 hbase 아티팩트의 릴리스를 만들 수 있어요.
시작하기 전에 (Before You Begin)
릴리스를 가져올 브랜치에서 최근 빌드가 통과했는지 확인하세요. 그리고 최근 브랜치 tip을 부하 상태의 클러스터에서 시도해 보세요. 예를 들어 hbase-it 통합 테스트 스위트를 몇 시간 동안 실행해 후보에 가까운 비트를 '번인'할 수 있어요.
hbase KEYS 파일에 추가된 공개된 서명 키가 필요해요. (KEY 추가 방법은 How To Release 문서의 Step 1을 참고하세요. 이 문서는 Hadoop 버전 문서예요.)
다음으로 JIRA가 제대로 준비됐는지, 예정된 릴리스를 대상으로 한 모든 이슈가 해결됐고 특정 브랜치의 git에 있는지 확인하세요. 미해결 이슈가 있으면 fix version을 조정해 이 대기 중인 릴리스를 대상에서 제외해 릴리스 밖으로 이동하세요. 릴리스 후보 대상 릴리스와 일치하는 fix version을 가진 모든 JIRA는 릴리스와 함께 제공되는 생성된 CHANGES.md/RELEASENOTES.md 파일에 포함되므로, 시작 전에 JIRA가 올바른지 확인하세요.
위 작업을 마치면 RC 제작으로 이동할 수 있어요.
RC 빌드는 복잡해서 스크립트로 만들었어요. 이 스크립트는 일관된 환경을 보장하기 위해 Docker 컨테이너에서 빌드해요. apache용 비밀번호와 gpg 서명 키 비밀번호를 물어보며, 대신 서명하고 커밋할 수 있도록 해요. 비밀번호는 컨테이너의 gpg-agent로 전달되고 빌드가 끝나면 컨테이너와 함께 제거돼요.
이 스크립트는 다음을 수행해요.
- 버전을 릴리스 버전으로 설정
- RELEASENOTES.md와 CHANGES.md 갱신
- RC 태그 지정
- 버전을 다음 SNAPSHOT 버전으로 설정
- 모든 아티팩트 빌드, 서명, 해시
- api 호환성 보고서 생성
- 릴리스 tgz를 apache dist의 dev 디렉터리로 푸시
- repository.apache.org staging으로 푸시
- 투표 이메일 템플릿 생성
dev-support/create-release/do-release-docker.sh RC 생성 스크립트는 master 브랜치에서 유지되지만 2.x+ 브랜치에서 RC를 생성할 수 있어요(이 스크립트는 branch-1에서는 작동하지 않아요). RC를 만들 때 master 브랜치를 체크아웃하고 갱신하세요. 환경 구성과 스크립트 실행 방법은 dev-support/create-release/README.txt를 참고해 주세요.
dev-support/create-release/do-release-docker.sh는 이전 dev-support/make_rc.sh 스크립트를 대체해요. 부분이 아니라 모든 단계를 자동화해 RC 빌드가 더 포괄적이에요.
릴리스 후보 절차 (Release Candidate Procedure)
여기서는 릴리스 후보 생성에 관련된 단계를 설명해요. 이 단계들은 이전 섹션에서 설명한 dev-support/create-release/do-release-docker.sh 스크립트가 자동화하는 것들이에요. 이 단계들을 수동으로 실행하면 오류가 발생하기 쉬우므로 권장하지 않아요. 아래는 정보 제공용일 뿐이에요.
아래 과정은 주로 git과 maven 등 다양한 도구를 사용해요.
Maven용 힙 공간 지정 (Specifying the Heap Space for Maven)
빌드 중, 특히 사이트와 문서를 빌드할 때 OutOfMemoryErrors가 발생할 수 있어요. MAVEN_OPTS 변수를 설정해 Maven의 힙을 늘리세요. 다음 예시와 같이 변수를 Maven 명령 앞에 붙일 수 있어요.
MAVEN_OPTS="-Xmx4g -XX:MaxPermSize=256m" mvn package
셸에서 환경 변수나 별칭으로 설정할 수도 있어요.
예시 ~/.m2/settings.xml 파일 (Example ~/.m2/settings.xml File)
maven에 게시하려면 업로드하려는 아티팩트에 서명해야 해요. 빌드가 서명을 해주게 하려면 로컬 저장소의 .m2 아래에 settings.xml이 제대로 구성되어 있어야 해요. 예를 들면 다음과 같아요.
<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
http://maven.apache.org/xsd/settings-1.0.0.xsd">
<servers>
<!- To publish a snapshot of some part of Maven -->
<server>
<id>apache.snapshots.https</id>
<username>YOUR_APACHE_ID
</username>
<password>YOUR_APACHE_PASSWORD
</password>
</server>
<!-- To publish a website using Maven -->
<!-- To stage a release of some part of Maven -->
<server>
<id>apache.releases.https</id>
<username>YOUR_APACHE_ID
</username>
<password>YOUR_APACHE_PASSWORD
</password>
</server>
</servers>
<profiles>
<profile>
<id>apache-release</id>
<properties>
<gpg.keyname>YOUR_KEYNAME</gpg.keyname>
<!--Keyname is something like this ... 00A5F21E... do `gpg ——list-keys` to find it-->
<gpg.passphrase>YOUR_KEY_PASSWORD
</gpg.passphrase>
</properties>
</profile>
</profiles>
</settings>
CHANGES.md 및 RELEASENOTES.md 파일과 POM 파일 갱신 (Update the CHANGES.md and RELEASENOTES.md files and the POM files)
마지막 릴리스 이후의 변경 사항으로 CHANGES.md를 갱신하세요. 현재 CHANGES.md와 RELEASENOTES.md에 있는 지침과 경고를 존중해 제목과 라이선스를 조심스럽게 배치하세요. 이 두 파일은 특정 문자열 시퀀스를 찾는 도구가 처리하거든요. CHANGES.md와 RELEASENOTES.md에 추가 사항을 생성하기 위해 yetus를 사용하는 방법은 HBASE-21399를 참고하세요(권장!). JIRA 수정을 추가할 때 이 릴리스의 수정을 나열하는 적절한 위치를 가리키도록 JIRA URL을 확인하세요.
다음으로 모든 POM 파일의 버전을 적절히 조정하세요. 릴리스 후보를 만든다면 모든 pom.xml 파일에서 모든 버전에서 -SNAPSHOT 라벨을 제거해야 해요. 스냅샷을 게시하기 위해 이 절차를 실행한다면 hbase 버전에 -SNAPSHOT 접미사를 유지해야 해요. Versions Maven Plugin이 여기서 유용할 수 있어요. hbase 다중 모듈 프로젝트의 많은 pom에서 버전을 설정하려면 다음 예시와 같은 명령을 사용하세요.
$ mvn clean org.codehaus.mojo:versions-maven-plugin:2.5:set -DnewVersion=2.1.0-SNAPSHOT
모든 pom의 버전이 변경되었는지 확인하세요! CHANGES.md, RELEASENOTES.md, 그리고 모든 maven 버전 변경 사항을 커밋하세요.
문서 갱신 (Update the documentation)
hbase-website/app/page/_docs/docs/_mdx/(multi-page) 아래의 문서를 갱신하세요. 보통 master에서 최신을 복사하고 이 릴리스 후보 버전에 맞는 버전별 조정을 하는 것을 포함해요. 변경 사항을 커밋하세요.
체크아웃 디렉터리 정리 (Clean the checkout dir)
$ mvn clean
$ git clean -f -x -d
Apache-Rat 실행 (Run Apache-Rat)
라이선스가 양호한지 확인하세요.
$ mvn apache-rat:check
위가 실패하면 rat 로그를 확인하세요.
$ grep 'Rat check' patchprocess/mvn_apache_rat.log
릴리스 태그 만들기 (Create a release tag.)
기본 테스트와 rat 검사가 통과하고 모든 것이 양호해 보인다면 이제 릴리스 후보를 태그할 때예요(다시 해야 하면 언제든 태그를 제거할 수 있어요). 태그하려면 빌드에 맞는 버전을 대입해 다음을 수행하세요. 모든 태그는 서명된 태그여야 해요. 즉 -s 옵션을 전달하세요(Signing Your Work에서 서명을 위한 git 환경 설정 방법 참고).
$ git tag -s 2.0.0-alpha4-RC0 -m "Tagging the 2.0.0-alpha4 first Releae Candidate (Candidates start at zero)"
또는 릴리스를 만든다면 태그에 rel/ 접두사가 있어야 Apache 저장소에 보존돼요. 예를 들면:
+$ git tag -s rel/2.0.0-alpha4 -m "Tagging the 2.0.0-alpha4 Release"
(특정) 태그만 푸시해 다른 사람이 접근할 수 있게 하세요.
$ git push origin 2.0.0-alpha4-RC0
태그 삭제 방법은 How to Delete a Tag를 참고하세요. 아직 원격 Apache 저장소로 푸시되지 않은 태그 삭제와 Apache로 푸시된 태그 삭제를 모두 다룬답니다.
소스 tarball 빌드 (Build the source tarball)
이제 소스 tarball을 빌드하세요. 예를 들어 태그 2.0.0-alpha4-RC0의 소스 tarball을 /tmp/hbase-2.0.0-alpha4-RC0/로 빌드한다고 가정해요(이 단계는 위에서 mvn과 git clean 단계를 방금 수행했어야 해요).
$ git archive --format=tar.gz --output="/tmp/hbase-2.0.0-alpha4-RC0/hbase-2.0.0-alpha4-src.tar.gz" --prefix="hbase-2.0.0-alpha4/" $git_tag
위에서 hbase-2.0.0-alpha4-src.tar.gz tarball을 /tmp/hbase-2.0.0-alpha4-RC0 빌드 출력 디렉터리로 생성해요(이름이나 접두사에 RC0을 넣고 싶지 않아요. 이 비트들은 현재 릴리스 후보지만 투표가 통과하면 릴리스가 되므로 아티팩트 이름을 RCX로 오염시키지 않아요).
바이너리 tarball 빌드 (Build the binary tarball)
다음으로 바이너리 tarball을 빌드하세요. 빌드할 때 -Prelease 프로파일을 추가하세요. 모든 것이 온전한지 확인하는 데 도움이 되는 apache-rat 라이선스 검사 등 다른 규칙을 실행해요. 두 단계로 하세요.
먼저 로컬 저장소에 설치하세요.
$ mvn clean install -DskipTests -Prelease
다음으로 문서를 생성하고 tarball을 조립하세요. 참고로 이 다음 단계는 꽤 오래 걸릴 수 있어요. 사이트 문서를 생성하는 데 몇 시간이 걸릴 수 있답니다.
$ mvn install -DskipTests site assembly:single -Prelease
그렇지 않으면 특히 새로운 저장소에서 한 단계로 모두 하려고 하면 빌드가 hbase 모듈이 maven 저장소에 없다고 불평해요. 두 단계 모두 install 목표가 필요한 것 같아요.
생성된 tarball을 추출하세요 — hbase-assembly/target 아래에서 찾을 수 있고 확인해 보세요. 문서를 보고, 실행되는지 등을 확인하세요. 좋다면 tarball을 빌드 출력 디렉터리의 소스 tarball 옆에 복사하세요.
Maven 저장소로 배포 (Deploy to the Maven Repository.)
다음으로 HBase를 Apache Maven 저장소에 배포하세요. mvn deploy 명령을 실행할 때 apache-release 프로파일을 추가하세요. 이 프로파일은 우리 pom 파일이 참조하는 Apache 부모 pom에서 나와요. settings.xml이 Example ~/.m2/settings.xml File에서 설명한 대로 올바르게 구성되어 있으면 Maven에 게시하는 아티팩트에 서명을 해줘요. 이 단계는 방금 전의 bin tarball 빌드로 로컬 저장소가 채워졌는지에 따라 달라져요.
$ mvn deploy -DskipTests -Papache-release -Prelease
이 명령은 모든 아티팩트를 'open' 상태의 임시 staging Apache mvn 저장소로 복사해요. 이 maven 아티팩트를 일반적으로 사용 가능하게 하려면 더 많은 작업이 필요해요.
우리는 HBase tarball을 Apache Maven 저장소로 릴리스하지 않아요. tarball 배포를 피하려면 mvn deploy 명령에 assembly:single 목표를 포함하지 마세요. 배포된 아티팩트를 다음 섹션에서 설명한 대로 확인하세요.
make_rc.sh
옛 dev-support/make_rc.sh 스크립트를 실행했다면 여기까지가 이 스크립트가 하는 일이에요. 릴리스를 끝내려면 여기부터 스크립트를 다시 시작하세요.
릴리스 후보를 사용 가능하게 만들기 (Make the Release Candidate available.)
아티팩트는 'open' 상태의 staging 영역의 maven 저장소에 있어요. 이 'open' 상태 동안 게시된 내용을 확인해 모두 좋은지 확인할 수 있어요. 그러려면 Apache ID로 repository.apache.org의 Apache Nexus에 로그인하세요. staging 저장소에서 아티팩트를 찾으세요. 'Staging Repositories'를 클릭하고 'hbase'로 끝나고 상태가 'Open'인 새 것을 찾아 선택하세요. tree 보기를 사용해 저장소 내용 목록을 확장하고 기대하는 아티팩트가 있는지 확인하세요. POM을 확인하세요. staging 저장소가 open인 동안 누락되거나 잘못 빌드된 것이 있으면 다시 업로드할 수 있어요.
심각하게 잘못되어 업로드를 되돌리고 싶다면 'Drop' 버튼을 사용해 staging 저장소를 드롭하고 삭제할 수 있어요. 때로는 업로드가 중간에 실패하기도 해요. 이것은 staging 저장소에서 업로드를 'Drop'해야 하는 또 다른 이유예요.
확인되면 'Close' 버튼으로 저장소를 닫으세요. 공개 URL이 생기기 전에 저장소를 닫아야 해요. 저장소가 닫히는 데 몇 분이 걸릴 수 있어요. 완료되면 Nexus UI에서 저장소의 공개 URL을 볼 수 있어요. URL이 포함된 이메일을 받을 수도 있어요. 릴리스 후보를 알리는 이메일에서 임시 staging 저장소의 URL을 제공하세요. (사람들은 게시된 릴리스 후보 아티팩트를 가져오려면 이 저장소 URL을 로컬 pom이나 로컬 settings.xml 파일에 추가해야 해요.)
릴리스 투표가 성공적으로 끝나면 여기로 돌아와 'Release' 버튼을 클릭해 아티팩트를 central에 릴리스하세요. 릴리스 과정은 staging 저장소를 자동으로 드롭하고 삭제해요.
hbase-downstreamer
HBase에 downstream이고 그것에 의존하는 프로젝트의 간단한 예시는 hbase-downstreamer 테스트를 보세요. 그것을 체크아웃하고 간단한 테스트를 실행해 maven 아티팩트가 maven 저장소에 제대로 배포됐는지 확인하세요. pom을 편집해 적절한 staging 저장소를 가리키는지 확인하세요. 테스트가 실행될 때 올바른 저장소에서 가져오고 있으며 로컬 저장소에서 가져오지 않는지 확인하세요. -U 플래그를 전달하거나 로컬 저장소 내용을 삭제하고 maven이 staging 저장소의 remote에서 가져오는지 확인하세요.
이 maven staging 과정에 대한 포인터는 Publishing Maven Artifacts를 참고하세요.
HBase 버전이 -SNAPSHOT으로 끝나면 아티팩트는 다른 곳으로 가요. Apache snapshots 저장소에 직접 넣고 즉시 사용 가능하게 돼요. SNAPSHOT 릴리스를 만든다면 이것이 원하는 결과예요.
이 단계에서 '빌드 출력 디렉터리'에 tarball 두 개와 'closed' 상태의 maven 저장소 staging 영역의 아티팩트 집합이 있어요. 다음으로 svnpubsub를 통해 dev distribution 디렉터리(여기 마지막에 있는 주석들과 HBASE-10554 Please delete old releases from mirroring system를 참고하세요. 본질적으로 dev/hbase의 svn 체크아웃이며 릴리스는 release/hbase에 있어요)에 디렉터리를 커밋함으로써 릴리스 후보 빌드 출력 디렉터리를 서명·지문·'stage'하세요. 버전 디렉터리에서 다음 명령을 실행하세요.
$ for i in *.tar.gz; do echo $i; gpg --print-md MD5 $i > $i.md5 ; done
$ for i in *.tar.gz; do echo $i; gpg --print-md SHA512 $i > $i.sha ; done
$ for i in *.tar.gz; do echo $i; gpg --armor --output $i.asc --detach-sig $i ; done
$ cd ..
# Presuming our 'build output directory' is named 0.96.0RC0, copy it to the svn checkout of the dist dev dir
# in this case named hbase.dist.dev.svn
$ cd /Users/stack/checkouts/hbase.dist.dev.svn
$ svn info
Path: .
Working Copy Root Path: /Users/stack/checkouts/hbase.dist.dev.svn
URL: https://dist.apache.org/repos/dist/dev/hbase
Repository Root: https://dist.apache.org/repos/dist
Repository UUID: 0d268c88-bc11-4956-87df-91683dc98e59
Revision: 15087
Node Kind: directory
Schedule: normal
Last Changed Author: ndimiduk
Last Changed Rev: 15045
Last Changed Date: 2016-08-28 11:13:36 -0700 (Sun, 28 Aug 2016)
$ mv 0.96.0RC0 /Users/stack/checkouts/hbase.dist.dev.svn
$ svn add 0.96.0RC0
$ svn commit ...
실제로 https://dist.apache.org/repos/dist/dev/hbase/를 확인해 게시됐는지 확인하세요.
메일링 리스트에 릴리스 후보를 알리고 투표를 요청하세요.
maven에 SNAPSHOT 게시 (Publishing a SNAPSHOT to maven)
settings.xml이 제대로 설정되어 있는지 확인하세요(Example ~/.m2/settings.xml File 참고). hbase 버전에 -SNAPSHOT 접미사가 포함되어 있는지 확인하세요. 다음은 pom에 hbase 버전이 0.96.0인 릴리스의 SNAPSHOT을 게시하는 예시예요.
$ mvn clean install -DskipTests javadoc:aggregate site assembly:single -Prelease
$ mvn -DskipTests deploy -Papache-release
위에서 언급한 make_rc.sh 스크립트(Making a Release Candidate 참고)가 SNAPSHOT 게시를 도와줄 수 있어요. 스크립트를 실행하기 전에 hbase.version에 -SNAPSHOT 접미사가 있는지 확인하세요. 그러면 apache snapshot 저장소에 스냅샷을 올려줄 거예요.