Goツールのリリースエンジニアリング
前回挙げた以下のリリース5段階の中で、バージョニングだけで1エントリになりましたが、今回は、2,3について。
- versionをbumpする
- CHANGELOGを更新する
- 1,2での変更をgitに反映してタグを打つ
- ビルドする
- ビルドをアップロードする
具体的には、リリースに纏わるファイル更新をgitに反映さえてタグを打つところまで。ビルドする直前までとも言えます。
CHANGELOG.mdを自動更新する
CHANGELOGは ghch で自動生成させている。規定の CHANGELOG.md をリポジトリに配置して、
% ghch -w -N $next_tag
とすれば、魔法のように CHANGELOG.md を更新してくれる。生成された CHANGELOG.md はこんな感じ。
https://github.com/Songmu/ghg/blob/master/CHANGELOG.md
CHANGELOG、あったほうが良いと思ってる派だけど、丁寧に書くのもメンドイし、とは言えコミットログをそのままCHANGELOGとするのも乱暴なので、 ghch を使ってpull requestの粒度でCHANGELOGとするのはまあ悪くないと思っている。
ghch についてはこちら。→
Gitのtagとpull requestのマージ履歴からChangelogを自動生成する ghch
gitの更新とそのためのリリーススクリプト
これで、 version.go と CHANGELOG.md が更新されているので、これらはもちろんgit repositoryに反映させる必要がある。そしてタグを打つ。これでリリース一段落である。
前回のエントリで書いたバージョンの更新作業から、git repository反映までを一撃でやるシェルスクリプトが以下。
#!/bin/sh
set -e
echo current version: $(gobump show -r)
read -p "input next version: " next_version
gobump set $next_version -w
ghch -w -N v$next_version
git commit -am "Checking in changes prior to tagging of version v$next_version"
git tag v$next_version
git push && git push --tags
これを、 _tools/releng とかに配置 している。Goのプロジェクトでこういうツール類を置くディレクトリは、個人的にはこの _tools/ のようにアンダースコアで始まるディレクトリに配置して、Goのソースコードが入ってないことをわかりやすくしているけど、そこまでやっている人あまり見ないので、やらなくても良いのかもしれない。 scripts/ とかに配置しているのもまま見ます。
ちなみに、たまに聞かれますが、 releng は Release engineering の略らしいです。一昔前にPerlハッカーの人たちが、CPANモジュールを上げるときに「relengする」ってよく言ってたのに影響されてます。
また、 Makefile に release みたいなターゲットを定義しておくと、 make release とかやれば、リリースが走ってくれるので便利。
release:
_tools/releng
残りはビルド
今回で git tag するところまで終了しました。後は、打たれたタグに対して成果物のビルドをおこない、適切なアップロードをすることを残すのみである。待て、次回。