リリースチェックリスト

Helmリリースのためのメンテナーガイド

新しいHelmリリースの時が来ました！ Helmメンテナーとしてリリースを行うあなたは、このリリースチェックリストを更新するのに最適な人物です。あなたの経験がここに記載されている内容と異なる場合は、更新してください。

すべてのリリースはvX.Y.Zの形式になります。ここでXはメジャーバージョン番号、Yはマイナーバージョン番号、Zはパッチリリース番号です。このプロジェクトはセマンティックバージョニングに厳密に従っているため、この手順に従うことが重要です。

Helmは次のマイナーリリースの日付を事前に発表します。発表された日付を尊重するためにあらゆる努力を払う必要があります。さらに、リリースプロセスを開始する際には、次のリリースの日付がリリースプロセスで使用されるため、選択しておく必要があります。

この手順では、初期設定と、3種類のリリースのリリースプロセスについて説明します。

メジャーリリース - リリース頻度が低い - 後方互換性を損なう変更が含まれる
マイナーリリース - 3～4ヶ月ごとにリリース - 後方互換性を損なう変更は含まれない
パッチリリース - 毎月リリース - このガイドのすべての手順は必要ない

初期設定

リリースブランチを作成する
メジャー/マイナーリリース：Gitのバージョン番号を変更する
メジャー/マイナーリリース：リリースブランチをコミットしてプッシュする
メジャー/マイナーリリース：リリース候補を作成する
メジャー/マイナーリリース：連続するリリース候補を反復処理する
リリースを完了する
リリースノートを書く
ダウンロードにPGP署名をする
リリースを公開する
ドキュメントを更新する
コミュニティに伝える

初期設定

Gitリモートを設定する

このドキュメントでは、リポジトリ内のhttps://github.com/helm/helmに対応するgitリモートの名前が「upstream」であると想定していることに注意することが重要です。そうでない場合（たとえば、「origin」など、別の名前にしている場合）、リストされているスニペットをローカル環境に合わせて調整してください。アップストリームリモートの名前がわからない場合は、git remote -vなどのコマンドを使用して確認してください。

アップストリームリモートがない場合は、次のようなコマンドを使用して追加できます。

git remote add upstream git@github.com:helm/helm.git

環境変数を設定する

このドキュメントでは、いくつかの環境変数も参照します。便宜上、設定しておくと便利です。メジャー/マイナーリリースの場合は、以下を使用します。

export RELEASE_NAME=vX.Y.0
export RELEASE_BRANCH_NAME="release-X.Y"
export RELEASE_CANDIDATE_NAME="$RELEASE_NAME-rc.1"

パッチリリースを作成する場合は、代わりに以下を使用します。

export PREVIOUS_PATCH_RELEASE=vX.Y.Z
export RELEASE_NAME=vX.Y.Z+1
export RELEASE_BRANCH_NAME="release-X.Y"

署名鍵を設定する

また、バイナリをハッシュ化し、署名ファイルを提供することにより、リリースプロセスのセキュリティと検証を追加します。これはGitHubとGPGを使用して行います。GPGをまだ設定していない場合は、次の手順に従ってください。

署名鍵を取得したら、リポジトリのルートにあるKEYSファイルにそれを追加する必要があります。KEYSファイルに追加する手順は、ファイルに記載されています。まだ行っていない場合は、公開鍵を鍵サーバーネットワークに追加する必要があります。GnuPGを使用する場合は、Debianが提供する手順に従うことができます。

1. リリースブランチを作成する

メジャー/マイナーリリース

メジャーリリースは、新機能の追加と、_後方互換性を損なう_動作変更のためのものです。マイナーリリースは、後方互換性を損なわない新機能の追加のためのものです。メジャーまたはマイナーリリースを作成するには、まずmainからrelease-X.Yブランチを作成します。

git fetch upstream
git checkout upstream/main
git checkout -b $RELEASE_BRANCH_NAME

この新しいブランチは、リリースのベースとなり、後で反復処理を行います。

GitHubにリリース用のhelm/helmマイルストーンが存在することを確認します（存在しない場合は作成します）。このリリースのPRとIssueがこのマイルストーンにあることを確認してください。

メジャー＆マイナーリリースの場合は、手順2に進みます：メジャー/マイナーリリース：Gitのバージョン番号を変更する。

パッチリリース

パッチリリースは、既存のリリースに対するいくつかの重要なチェリーピックされた修正です。まず、release-X.Yブランチを作成します。

git fetch upstream
git checkout -b $RELEASE_BRANCH_NAME upstream/$RELEASE_BRANCH_NAME

ここから、パッチリリースに取り込みたいコミットをチェリーピックできます。

# get the commits ids we want to cherry-pick
git log --oneline
# cherry-pick the commits starting from the oldest one, without including merge commits
git cherry-pick -x <commit-id>

コミットがチェリーピックされた後、リリースブランチをプッシュする必要があります。

git push upstream $RELEASE_BRANCH_NAME

ブランチをプッシュすると、テストが実行されます。タグを作成する前に、テストがパスすることを確認してください。この新しいタグは、パッチリリースのベースになります。

helm/helmマイルストーンの作成は、パッチリリースではオプションです。

続行する前に、CircleCI上のhelmをチェックして、リリースがCIに合格したことを確認してください。パッチリリースは手順2〜5をスキップし、手順6のリリースのファイナライズに進むことができます。

2. メジャー/マイナーリリース：Gitのバージョン番号を変更する

メジャーまたはマイナーリリースを行う場合は、internal/version/version.goを新しいリリースバージョンで更新してください。

$ git diff internal/version/version.go
diff --git a/internal/version/version.go b/internal/version/version.go
index 712aae64..c1ed191e 100644
--- a/internal/version/version.go
+++ b/internal/version/version.go
@@ -30,7 +30,7 @@ var (
        // Increment major number for new feature additions and behavioral changes.
        // Increment minor number for bug fixes and performance enhancements.
        // Increment patch number for critical fixes to existing releases.
-       version = "v3.3"
+       version = "v3.4"

        // metadata is extra build time data
        metadata = ""

version.goファイル内のバージョンを更新することに加えて、そのバージョン番号を使用している対応するテストも更新する必要があります。

cmd/helm/testdata/output/version.txt
cmd/helm/testdata/output/version-client.txt
cmd/helm/testdata/output/version-client-shorthand.txt
cmd/helm/testdata/output/version-short.txt
cmd/helm/testdata/output/version-template.txt
pkg/chartutil/capabilities_test.go

git add .
git commit -m "bump version to $RELEASE_NAME"

これは$RELEASE_BRANCH_NAMEに対してのみ更新されます。また、この3.2から3.3への例のように、次のリリースが作成されるときに、この変更をmainブランチにプルし、次のリリースのマイルストーンに追加する必要があります。

# get the last commit id i.e. commit to bump the version
git log --format="%H" -n 1

# create new branch off main
git checkout main
git checkout -b bump-version-<release_version>

# cherry pick the commit using id from first command
git cherry-pick -x <commit-id>

# commit the change
git push origin bump-version-<release-version>

3. メジャー/マイナーリリース：リリースブランチをコミットしてプッシュする

他の人がテストを開始できるように、リリースブランチをアップストリームにプッシュして、テストプロセスを開始できます。

git push upstream $RELEASE_BRANCH_NAME

続行する前に、CircleCI上のhelmをチェックして、リリースがCIに合格したことを確認してください。

可能であれば、続行する前に、他の担当者にブランチをピアレビューしてもらい、適切な変更がすべて行われ、リリースのコミットがすべて揃っていることを確認してください。

4. メジャー/マイナーリリース：リリース候補を作成する

リリースブランチが準備できたので、リリース候補の作成と反復を開始します。

git tag --sign --annotate "${RELEASE_CANDIDATE_NAME}" --message "Helm release ${RELEASE_CANDIDATE_NAME}"
git push upstream $RELEASE_CANDIDATE_NAME

CircleCIは、テスト用にタグ付けされたリリースイメージとクライアントバイナリを自動的に作成します。

テスターにとって、CircleCIによる成果物のビルド完了後にテストを開始するプロセスには、クライアントを取得するための以下の手順が含まれます。

linux/amd64、/bin/bashを使用

wget https://get.helm.sh/helm-$RELEASE_CANDIDATE_NAME-linux-amd64.tar.gz

darwin/amd64、Terminal.appを使用

wget https://get.helm.sh/helm-$RELEASE_CANDIDATE_NAME-darwin-amd64.tar.gz

windows/amd64、PowerShellを使用

PS C:\> Invoke-WebRequest -Uri "https://get.helm.sh/helm-$RELEASE_CANDIDATE_NAME-windows-amd64.tar.gz" -OutFile "helm-$ReleaseCandidateName-windows-amd64.tar.gz"

次に、バイナリを解凍し、$PATH上のどこかに移動するか、どこかに移動して$PATHに追加します（例：linux/macOSの場合は/usr/local/bin/helm、Windowsの場合はC:\Program Files\helm\helm.exe）。

5. メジャー/マイナーリリース：連続するリリース候補の反復

数日間かけて、時間とリソースを明示的に投入し、helmをあらゆる方法で壊そうとし、リリースに関連するすべての調査結果を文書化します。この時間は、コーディングではなく、テストを行い、リリースによってさまざまな機能やアップグレード環境に問題が発生する可能性のある方法を見つけることに費やす必要があります。この間、リリースはコードフリーズ状態になり、追加のコード変更は次のリリースにプッシュされます。

このフェーズでは、新しいリリース候補を作成するため、$RELEASE_BRANCH_NAME ブランチは進化し続けます。新しい候補の頻度は、リリースマネージャー次第です。報告された問題の重大度、テスターの可用性、リリースの締め切り日を考慮して、最善の判断を下してください。一般的に、壊れたリリースを出荷するよりも、リリースの締め切りを過ぎても構いません。

新しいリリース候補を作成するたびに、まずmainからコミットをcherry-pickしてブランチに追加します。

git cherry-pick -x <commit_id>

また、ブランチをGitHubにプッシュし、CIに合格することを確認する必要があります。

その後、タグを付け、ユーザーに新しいリリース候補を通知します。

export RELEASE_CANDIDATE_NAME="$RELEASE_NAME-rc.2"
git tag --sign --annotate "${RELEASE_CANDIDATE_NAME}" --message "Helm release ${RELEASE_CANDIDATE_NAME}"
git push upstream $RELEASE_CANDIDATE_NAME

GitHubにプッシュしたら、このタグが付いたブランチがCIでビルドされることを確認してください。

ここから先は、リリース候補に満足するまで、このプロセスを繰り返し、継続的にテストします。リリース候補の場合、完全なノートは書きませんが、リリースノートの骨組みを作成できます。

6. リリースの最終決定

リリース候補の品質に最終的に満足したら、先に進んで、正式なリリースを作成できます。最後にすべてが順序どおりであることをもう一度確認し、リリースタグをプッシュします。

git checkout $RELEASE_BRANCH_NAME
git tag --sign --annotate "${RELEASE_NAME}" --message "Helm release ${RELEASE_NAME}"
git push upstream $RELEASE_NAME

CircleCIでリリースが成功したことを確認します。成功しなかった場合は、リリースを修正し、リリースを再度プッシュする必要があります。

CIジョブの実行には時間がかかるため、完了を待つ間にリリースノートの作成に進むことができます。

7. リリースノートの作成

リリースサイクル中に発生したコミットに基づいて変更ログを自動生成しますが、通常、リリースノートが人間/マーケティングチーム/犬によって手書きされている場合、エンドユーザーにとってより有益です。

メジャー/マイナーリリースをリリースする場合は、注目すべきユーザー向けの機能をリストするだけで十分です。パッチリリースの場合は、同じようにしますが、症状と影響を受ける人をメモしてください。

リリースノートには、次のリリースのバージョンと予定日が含まれている必要があります。

マイナーリリースのリリースノートの例は次のとおりです。

## vX.Y.Z

Helm vX.Y.Z is a feature release. This release, we focused on <insert focal point>. Users are encouraged to upgrade for the best experience.

The community keeps growing, and we'd love to see you there!

- Join the discussion in [Kubernetes Slack](https://kubernetes.slack.com):
  - `#helm-users` for questions and just to hang out
  - `#helm-dev` for discussing PRs, code, and bugs
- Hang out at the Public Developer Call: Thursday, 9:30 Pacific via [Zoom](https://zoom.us/j/696660622)
- Test, debug, and contribute charts: [Artifact Hub helm charts](https://artifacthub.io/packages/search?kind=0)

## Notable Changes

- Kubernetes 1.16 is now supported including new manifest apiVersions
- Sprig was upgraded to 2.22

## Installation and Upgrading

Download Helm X.Y. The common platform binaries are here:

- [MacOS amd64](https://get.helm.sh/helm-vX.Y.Z-darwin-amd64.tar.gz) ([checksum](https://get.helm.sh/helm-vX.Y.Z-darwin-amd64.tar.gz.sha256sum) / CHECKSUM_VAL)
- [Linux amd64](https://get.helm.sh/helm-vX.Y.Z-linux-amd64.tar.gz) ([checksum](https://get.helm.sh/helm-vX.Y.Z-linux-amd64.tar.gz.sha256sum) / CHECKSUM_VAL)
- [Linux arm](https://get.helm.sh/helm-vX.Y.Z-linux-arm.tar.gz) ([checksum](https://get.helm.sh/helm-vX.Y.Z-linux-arm.tar.gz.sha256) / CHECKSUM_VAL)
- [Linux arm64](https://get.helm.sh/helm-vX.Y.Z-linux-arm64.tar.gz) ([checksum](https://get.helm.sh/helm-vX.Y.Z-linux-arm64.tar.gz.sha256sum) / CHECKSUM_VAL)
- [Linux i386](https://get.helm.sh/helm-vX.Y.Z-linux-386.tar.gz) ([checksum](https://get.helm.sh/helm-vX.Y.Z-linux-386.tar.gz.sha256) / CHECKSUM_VAL)
- [Linux ppc64le](https://get.helm.sh/helm-vX.Y.Z-linux-ppc64le.tar.gz) ([checksum](https://get.helm.sh/helm-vX.Y.Z-linux-ppc64le.tar.gz.sha256sum) / CHECKSUM_VAL)
- [Linux s390x](https://get.helm.sh/helm-vX.Y.Z-linux-s390x.tar.gz) ([checksum](https://get.helm.sh/helm-vX.Y.Z-linux-s390x.tar.gz.sha256sum) / CHECKSUM_VAL)
- [Windows amd64](https://get.helm.sh/helm-vX.Y.Z-windows-amd64.zip) ([checksum](https://get.helm.sh/helm-vX.Y.Z-windows-amd64.zip.sha256sum) / CHECKSUM_VAL)

The [Quickstart Guide](https://docs.helm.sh/using_helm/#quickstart-guide) will get you going from there. For **upgrade instructions** or detailed installation notes, check the [install guide](https://docs.helm.sh/using_helm/#installing-helm). You can also use a [script to install](https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3) on any system with `bash`.

## What's Next

- vX.Y.Z+1 will contain only bug fixes and is planned for <insert DATE>.
- vX.Y+1.0 is the next feature release and is planned for <insert DATE>. This release will focus on ...

## Changelog

- chore(*): bump version to v2.7.0 08c1144f5eb3e3b636d9775617287cc26e53dba4 (Adam Reese)
- fix circle not building tags f4f932fabd197f7e6d608c8672b33a483b4b76fa (Matthew Fisher)

変更ログを含む、部分的に完成したリリースノートは、次のコマンドを実行することで作成できます。

export VERSION="$RELEASE_NAME"
export PREVIOUS_RELEASE=vX.Y.Z
make clean
make fetch-dist
make release-notes

これにより、優れたベースラインのリリースノートが作成され、**注目すべき変更**と**今後の予定**のセクションを入力するだけで済みます。

リリースノートに自分の意見を追加してください。私たちがすべてロボットではないと思うのは良いことです。

また、自動生成されたリリースノートでURLとチェックサムが正しいことを再確認する必要があります。

完了したら、GitHubにアクセスしてhelm/helm リリースに移動し、ここで記述したノートを使用して、タグ付けされたリリースのリリースノートを編集します。ターゲットブランチには、$RELEASE_BRANCH_NAMEを設定します。

リリースが公開される前に、他の人にリリースノートを見てもらう価値があります。レビューのために#helm-devにリクエストを送信してください。見落としがちなので、常に有益です。

8. ダウンロードにPGP署名する

ハッシュは、ダウンロードの内容が生成されたものであるという署名を提供しますが、署名付きパッケージは、パッケージの出所を追跡できます。

これを行うには、次のmakeコマンドを実行します。

export VERSION="$RELEASE_NAME"
make clean		# if not already run
make fetch-dist	# if not already run
make sign

これにより、CIによってプッシュされた各ファイルのASCII armored署名ファイルが生成されます。

すべての署名ファイル（*.asc）をGitHubのリリースにアップロードする必要があります（バイナリを添付）。

9. リリースを公開する

リリースを公式にする時が来ました！

リリースノートがGitHubに保存され、CIビルドが完了し、署名ファイルをリリースに追加したら、リリースの「公開」をクリックできます。これにより、リリースが公開され、「最新」としてリストされ、helm/helmリポジトリのフロントページにこのリリースが表示されます。

10. ドキュメントの更新

Helmウェブサイトのドキュメントセクションには、ドキュメントのHelmバージョンがリストされています。メジャー、マイナー、およびパッチバージョンは、サイトで更新する必要があります。次のマイナーリリースの日付もサイトに公開されており、更新する必要があります。そのためには、helm-wwwリポジトリに対してプルリクエストを作成します。 config.tomlファイルで適切なparams.versionsセクションを見つけ、現在のバージョンの更新のこの例のように、Helmバージョンを更新します。同じconfig.tomlファイルで、params.nextversionセクションを更新します。

該当する場合、リリースのhelm/helm マイルストーンを閉じます。

メジャーおよびマイナーリリースのバージョンスキューを更新します。

リリースカレンダーをこちらで更新します

次のマイナーリリースのエントリを、その日の午後5時（GMT）にリマインダー付きで作成します
次のマイナーリリースのRC1のエントリを、予定されているリリースの1週間前の月曜日に、その日の午後5時（GMT）にリマインダー付きで作成します

11. コミュニティに伝える

おめでとうございます！これで完了です。$DRINK_OF_CHOICEを手に入れましょう。あなたはそれを獲得しました。

素敵な$DRINK_OF_CHOICEを楽しんだ後、SlackとTwitterでGitHubのリリースへのリンクを付けて、新しいリリースを発表しましょう。

オプションで、新しいリリースに関するブログ記事を作成し、そこでいくつかの新機能を紹介してください！