Project

General

Profile

Main »

リリース作業手順

メンテナンスブランチの場合

1. 日々淡々とバックポートを行う。

ちなみにバックポートの方法は

ruby trunk-src-dir/tool/merger.rb --ticket=バックポートチケットの番号 リビジョン番号,リビジョン番号,...

である。チケットの番号、リビジョン番号は数字のみで。

バックポートチケットがないこともあるので、その場合は--ticket=は省略。

バックポート元がない修正の場合は手動でコミットすることになるが、コミットの前に

ruby trunk-src-dir/tool/merger.rb revisionup

を忘れずに。適切にversion.hを更新してくれる。

なお、ここで使うrubyおよびmerger.rbはtrunk最新が望ましい。
他のブランチのmerger.rbはバグったままであることが多い(いちいちバックポートしない)ので、これが安心確実。
何か不都合があったら、ちゃんと直してtrunkにコミットしておこう。

ちなみに、チケット番号を入れ忘れた場合、コミットメッセージはもちろんもはや変えられないが、Redmine側は
リビジョンのページ からチケットを紐付けることが出来る。

なお、セキュリティissueについては別途取り扱われているので、非公開ドキュメントに記載してある「対応手順」を確認すること

2. じっとRubyCIを眺め続ける。

更新されるまで時間がかかるので気長に待つこと。

原則として、RubySpecを含めて、問題がいっさいない場合しかリリースしない。EかFがあったら1.に戻ろう。
ただし、プラットフォーム特有の何かとか、タイミングによって起きたりするエラーは往々にしてあるので、その辺は以前のリリース時の結果も踏まえて臨機応変に。
RubySpecのバグとかもたまにあるので、見つけたら報告して直してもらう。

3. 機が熟したと思ったら、タグを打つ。

タグの打ち方は、

ruby trunk-src-dir/tool/merger.rb tag

である。

previewやrcの場合は、

ruby trunk-src-dir/tool/merger.rb tag 2.5.0-rc1

などと、明確に対象を引数として指定する必要がある。

※ できごころでpreview/rcをalphaやbetaにしないように。Gem::Versionの比較順はdev<preview<rcという順序を前提にしているため、devを指定しているgemがalphaだと壊れる

ミスが発覚したなど、なんらかの理由でタグを消す場合は、以下のようにする。

ruby trunk-src-dir/tool/merger.rb removetag 2.5.0-rc1

4. GitHub Actions でパッケージを作る。

以下のどれかの方法でスタートする。

a. https://github.com/ruby/actions/actions/workflows/draft-release.yml
で「This workflow has a workflow_dispatch event trigger.」の横の「Run workflow」でバージョンを指定して Run workflow する。

b. https://github.com/ruby/actions の tool/trigger-draft-release.sh をタグを引数にして実行する。 

git pull 
./tool/trigger-draft-release.sh v2_5_0_rc1

c. webhook 経由で実行する。(hub コマンドを使っていて ~/.config/hub から読めるなら TOKEN は省略可能)

 TOKEN=githubのoauthのrepo権限のあるtoken ./tool/trigger-snapshot.sh refs/tags/v2_5_0_rc1

Slack に通知が届いたら Amazon S3 s3://ftp.r-l.o/ のpub/tmp/ にパッケージがアップロードされているのを確認する。

何か問題があれば https://github.com/ruby/actions/actions?workflow=Make+draft+release+package からログを見て修正する。

5. できたパッケージをテストする

RubyCIで緑だから、といって油断はできないので、ちゃんとパッケージ自体をテストする必要がある。
また、なるべく多様な環境で確認することが望ましい。
特にRails使いに確認してもらうと安心度がぐっと上がる。

テストに際しては、configure時に --with-baseruby=noruby などとして、rubyがない環境でビルドできることも確認すること

6. もう大丈夫かなーと思ったらリリースする。

テスト配布をしていたならばそれをちゃんと削除して、その上でリリースを行うことになる。
なお、マズった、と思ったら、3.で打ったタグを削除(3.を参照)して1.に戻る。

リリースとは要するに公開ディレクトリにパッケージファイルを置くことである。
具体的には以下の通り。

  1. Amazon S3の s3://ftp.r-l.o の pub/ruby/X.X/ 以下にパッケージファイルをアップロードして、
  2. (2.6.X までは) pub/ruby/ 直下にもコピーを置いて、
  3. (2.6.X までは) さらに pub/ruby/ 直下に ruby-2.X-stable.各拡張子 というコピーも作る(既にあるのを上書きする)

tool/release.sh を使ってもよい。

7. へこへことリリースアナウンスを書いてwww.ruby-lang.orgに掲載する。

とりあえず日英の2箇所を更新するのが自分の責任範囲だと思ってよい。最悪英語だけでもいいが。
よくわからんかったら前回のアナウンス文面を穴があくほど見つめるとよい。

アナウンス文中にはダウンロードURLやハッシュ値を書くことになる。
4.でコピペしておいた内容を転記するわけだが、パッケージのパスを有効なURLに書き換えるのを忘れないように。
なおURLは https://cache.ruby-lang.org/pub/ruby/2.4/ruby-2.4.3.拡張子 になる。

文面はmarkdownで書いて、https://github.com/ruby/www.ruby-lang.org をforkしてpull reqするのが正規の手順である。
なお、dateメタフィールドに未来の日時を入れるとデプロイに失敗する。いろいろ言いたいことはあるが、ぐっとこらえて、pull reqがマージされるであろう時刻(=stagingに記事が掲載される時刻)より前の時刻を推定して記載しておくこと。
_data/releases.yml や _data/download.yml 内にリリースしたパッケージの情報の記述があるので、それを更新するのも忘れないように。これを忘れるとダウンロードページが更新されない。

無事にmasterにマージされたら(または自分でマージしたら)、以下の手順でデプロイする。

  1. https://github.com/ruby/www.ruby-lang.org のmasterにマージされた時点で、Travis CIでテストビルドが行われる。
  2. Travis CIのテストビルドが成功すれば、今度はstaging環境向けのビルドおよびデプロイが行われる。
  3. staging環境でチェックが完了したら、Herokuのpromoteボタンを押すか、またはSlackの適切なチャンネルで /h promote www-ruby-lang to production と叫ぶと、ほぼ即座に本番環境に反映される。
  4. ただし、本番環境サイトのコンテンツはfastlyでキャッシュされているので、これだけではユーザーには更新内容が見えない。 よって、Fastlyにログインして、上部からconfigure → Serviceからw.r-l.o → Purge → Purge Allを押してキャッシュをパージするか、Slackの適切なチャンネルで @ruboty fastly purge all www と叫ぶ。

8. アナウンス文面を適当に書いてruby-listとruby-talkに投げる

単に英語でだけ書いてruby-listとruby-talkに同時に投げるとか、日英併記してruby-listとruby-talkに同時に投げるとか、で特に誰からも苦情は来ないとは思うが、日本語はruby-listに、英語はruby-talkに、と丁寧に投げ分けるとちょっと親切かもしれない。メールを投げるときにはPGP鍵で署名しておくといいかもしれない。
previewやrcの場合はruby-devとruby-coreでも可。

9. もしあなたが業務として保守作業を行っているなら、報告書への記載を忘れずに :)

10. これですべき作業は全てである。お疲れ様でした。

後はTwitterでリリースした旨をつぶやいてRT数を稼ごう :)

リリース後関連作業

リリース後のリリースに関連する作業のリストです。
手を動かす人はリリースした人とは関係ないものも含まれます。

初回リリース(X.Y.0)の時

EOL

初回リリース(X.Y.0)の場合の特記事項、追加作業について

preview、rcについて

  1. 基本的な手順はおおむね上記と同じ。ただ、タグ名が変わるので、そこだけ注意。 具体的には、merger.rbでのタグ打ちの際に、「2.2.0-preview1」などという引数を付加する。 この際、RUBY_PATCHLEVELが-1以外だとエラーになる。
  2. make-snapshotでできたパッケージ名およびパッケージ内のディレクトリが「ruby-2.2.0-preview1」などになる。 また、ruby -vが自動的に「ruby 2.2.0preview1」などになる。 なってなかったらタグ名がおかしいか、make-snapshotがバグってるかどちらか。

初回の正式リリースについて

  1. 新ブランチを作る（作らないとパッチレベルを変えられない）
  2. 事前に、version.hのRUBY_PATCHLEVELを0に変える。コミットを忘れずに。
  3. merger.rbでのタグ打ちの際は、「2.2.0」などという引数を付加する。この際、RUBY_PATCHLEVELが0以外だとエラーになる。
  4. make-snapshotでできたパッケージ名およびパッケージ内のディレクトリが「ruby-2.2.0」などになる。 また、ruby -vが自動的に「ruby 2.2.0p0」などになる。 「ruby 2.2.0dev」とかのままなら、たぶん(2)ができてない。
  5. .travis.ymlに新ブランチを追加する
  6. matzにtrunkバージョンアップの儀を催促する include/ruby/version.hも変えてもらう
  7. RedmineのBackport欄のデフォルト に新バージョンを足す
  8. git.r-l.o<->GitHub双方向同期ブランチへの追加: https://github.com/ruby/ruby-commit-hook/commit/9f345412d4836e5e9c7998e89535908fc571d0ca
% svn cp -m "stable branch of Ruby 2.3" svn+ssh://svn@ci.ruby-lang.org/ruby/trunk svn+ssh://svn@ci.ruby-lang.org/ruby/branches/ruby_2_3
% cd ..
% svn co svn+ssh://svn@ci.ruby-lang.org/ruby/branches/ruby_2_3
% cd ruby_2_3
% vi version.h # #define RUBY_PATCHLEVEL 0
% svn ci
% merger.rb tag 2.3.0
% autoconf

% mkdir ~/obj/ruby_2_3
% ../../src/ruby_2_3/configure --disable-install-doc --enable-shared --without-tk --with-opt-dir=/usr/local --prefix=/home/naruse/local/ruby_2_3
% make Makefile;make Makefile&&make -j8 install-nodoc
% rm tmp/ruby-*;make dist RELNAME=2.3.0
%  for file in `ls tmp`; do
 aws --profile ruby s3 cp tmp/$file s3://ftp.r-l.o/pub/ruby/2.6/$file
done