リリース運用の再考

[samunohito]

Summary

文章力が限界なので考えてることを箇条書きします

• 機能が壊れているなど急を要する場合は即時リリースが出来るような感じにしたい（master -> hotfixブランチ -> masterみたいな）
• リリースの規模を小さくしたい（大規模な修正が1件、小規模な修正が数件くらいのサイズ）
• 小さくした分、少しリリース間隔を狭めたい（だいたい1週間前後目安で）

なぜこんなことを考えたかというと、

• リリース時の負荷が高い（確認作業など）
• betaを長くとっても網羅しきれない（意識して確認しておきたいところが分からない）
• バグフィクスをmasterに届けるのが遅くなる

Purpose

• リリース時の負荷が減る
• 確認点が明確になることでバグを取り除きやすくなる（品質が上がる）
• バグフィクスをリリースしやすくなりサーバ管理者各位・ユーザ各位にとってやさしい

[samunohito]

過去にあった提案。これを軸にしてもいいかもしれない
#10806 (comment)

[syuilo]

過去にあった提案。これを軸にしてもいいかもしれない #10806 (comment)

そんな感じが理想だけどその通り運用できる自信がないわね(色々忘れそう)

[kakkokari-gtyih]

過去にあった提案。これを軸にしてもいいかもしれない #10806 (comment)

そんな感じが理想だけどその通り運用できる自信がないわね(色々忘れそう)

PRを自動でGithubのマイルストーンに紐付けるBotを組んで運用すればいいかも

PRを確認したら、重要度別のラベルを貼ってやると、それをもとにBotがマイルストーンを振り分けるとか

[syuilo]

🆒

[samunohito]

さすがすぎる

[syuilo]

ここにMisskeyリポジトリの運用を一部自動化するためのBotを作ろうとした残骸がある
https://github.com/misskey-dev/github-keeper

[samunohito]

• GitHubのマイルストーン機能を使えば管理の自動化が出来そう
• 入れるタイミングはタグにより判断できそう
• リポジトリは既にあるので、そこに機能を増やしていけばよさそう

手段はなんとかなりそうなので、あとはその手段を活かすための運用の中身か…

[samunohito]

• カレンダーバージョニングにする #10806 (comment) でいく
• 今の運用を小粒にしたイメージ（ただし冒頭の内容のように取り込み数を制限する）でいく

でだいぶ変わってきますが、どっちでいきますか

[syuilo]

前者にするかしら

[samunohito]

例えば第三日曜でそのリリースに入れる機能の受付を締め切ってリリース用ブランチを切り
レビュー期間に入って第四土曜以降に最初のリリースを行い

このあたりのスケジュール間隔はそのままでよさそうですか？
書き込み当時の様子を知らないので何とも言えないのですが、今はだいぶ活発なように見えるので調整の余地があると考えてます

[syuilo]

Misskey Hubの更新なども含めてリリース作業自体を自動で行ってくれるBotが欲しくなってきた(人間はapproveするだけ)

[tamaina]

どんな手動作業があるのかしら

[tamaina]

（リリースノートなら https://docs.github.com/ja/repositories/releasing-projects-on-github/automatically-generated-release-notes がある程度解決しそう？

[syuilo]

どんな手動作業があるのかしら

様々なボタンをぽちぽちする

[syuilo]

リリースノート然り、package.jsonバージョンの更新とか、GitHub Releaseのバージョン名入力とか、人間がやるとミスしそうなポイントがいくつもある(実際ミスしてる)

[samunohito]

tamainaさんの貼ってくれたやつとかActionsとか組み合わせたらうまいこと解決できそうではあるかも

[anatawa12]

https://github.com/anatawa12/AvatarOptimizer/blob/master/.github/workflows/release.yml

リースノートは人間向けなので自動化はあまり良くないと思ってますが(validationは賛成) package.json等の更新は現在進行系で使ってる例があります(master一本運用なのでマージ等改修必須ですが)

[kakkokari-gtyih]

Misskey Hubの更新なども含めて

これはビルド時にChangelogを取得して反映とかでうまいことできそう

[tamaina]

package.jsonが変だったらマージを防止するぐらいでもいいような気はするけど、そもそも「次のリリース名の定義」ってどうやって持たせればいいんだ

[samunohito]

（今日明日は忙しいけど、一息ついたらここまでの流れと残課題を整理＆botの要件取りまとめをしたい）

[anatawa12]

そもそも「次のリリース名の定義」ってどうやって持たせればいいんだ

一応私の回してる自動リリースでは

• 次のバージョンのベータで示す
• ベータの中の次のバージョンは数字の部分を-1した状態(=前回のベータリリースの状態)でブランチにおいておく

という形で回ってるのでどうにかはなります

[tai-cha]

年末年始は時間があるしある程度のそういう自動化・半自動化は得意分野なので取り組むのであれば私も何かしらはできるかもしれないですね〜

[tamaina]

リリースが多すぎて追いつけない

開発速度が異常な以上はついてきてもらうほかないんじゃない
あと昔と違ってDockerが割とまともに整備されている（たぶん）のでついてこれるサーバーは多くなっていると思う

（個人的には2日おきにリリースしてもいいと思っている）

[tamaina]

（個人的には2日おきにリリースしてもいいと思っている）

なんか世間的には2日おきはついてこれないレベルらしい(

[FineArchs]

開発が早すぎて変更の把握が追いつかないってことはまああると思うんですけど、それがリリース期間を長く取ることで改善されるわけではないように思います。（時間あたりの変更量は変わらないため）

[FineArchs]

あるいは、リリースの度にアップデートの作業をするのが負担だという話？
必ずしも毎回取り込む必要はなく、何回分か飛ばす選択肢もあるということが周知されていない？

[syuilo]

こんなんでどうじゃろ（割と議論ガン無視で味付けしたけど

人間がやることは任意のタイミングでpackage.jsonのversionを更新することとPRをready/マージすることだけ？

[tamaina]

人間がやることは任意のタイミングでpackage.jsonのversionを更新することとPRをready/マージすることだけ？

人間がpackage.jsonやPRのマージに触ってはいけない(readyは触る)

workflow dispatchで全自動で行われる

[syuilo]

package.jsonの更新とPRの作成は勝手にスケジュールに沿って行われる感じかしら

[tamaina]

workflow dispatchとcronはお好みで選べる

[samunohito]

やりたい

[syuilo]

新しい運用方法まとめあるかしら

[tamaina]

[tamaina]

( https://github.com/joinmisskey/release-actions で動いているので実際に動かすとわかりやすいかもしれない

[syuilo]

自分の知能では理解できなさそう

[tamaina]

Workflows

リポジトリに3つのワークフローを置く

1. Workflow Dispatch(Run workflow)で操作するメインワークフロー
2. CHANGELOG.mdが変わった時にPRの説明を書き換えるワークフロー
3. Ready for Reviewした時自動的にrcリリースを作成するワークフロー

「リリースコミット作成」とは

「リリースコミット作成」機能は次の操作が実行される

• package.jsonのversionを書き換え
• gitタグの追加
• GitHubでリリース
  この時CHANGELOG.mdの内容がリリースの説明文に追加される

Phase 0: 開発

masterブランチで新機能の取り込みをする

Targetの作成

リリースPRがない状態でメインワークフローをDispatchすると、次の操作が実行される

1. 次のバージョンを決定
2. リリースブランチ作成
3. ブランチをもとにリリースPRを作成
4. beta.0リリースコミット作成
5. CHANGELOG.mdのUnreleasedタイトルをバージョンに書き換え
6. rulesetの切り替え
   整合性のためにmasterブランチをロックする

Phase 1: リリースに専念

やること

• バグ取り
• CHANGELOG.mdの編集

ここでメインワークフローを(MERGE...にチェックを入れずに)操作すると、betaリリースが作成される

Ready for Review

PRをReady for Reviewにするとrcリリースが発行される

（rcリリースの番号はbetaの続き、GitHubの使用上draftに戻せるがそれだとコンフリクトするため）

Phase 2: Release Candidate

RCで最終確認する

Phase 3: Publish The Release

メインワークフローをMERGE RELEASE BRANCH TO MAINにチェックを入れてDIspatchすれば、正式リリースが発行される

次の操作が実行される

• まずマージ可能性をチェックする
  • Approveが必要
• 正式版リリースコミットを作成
• rulesetの切り替え
  masterブランチのロック解除
• CHANGELOG.mdにテンプレートを追加

→ Phase 0に戻る

[tamaina]

release/ブランチができるの議論の流れとは逆だけど、PRベースでやるにはそうするしかない

（そういう面ではmaster-developの方がいいのだけれど？）

[tamaina]

release(もしくはdevelop)のバグフィックスと並行してmasterへ機能を追加するのは破綻する（正式リリースでマージする際にコンフリクトが発生したりreleaseのバグ修正をmasterへ反映しにくくなるため）

（こういった面でもmaster-developの方がいいのだけれど？）

[tamaina]

(master-developシステムを推奨したからと言ってmaster-develop用のスクリプトが準備されているわけではない)

[tamaina]

release(もしくはdevelop)のバグフィックスと並行してmasterへ機能を追加するのは破綻する（正式リリースでマージする際にコンフリクトが発生したりreleaseのバグ修正をmasterへ反映しにくくなるため）

（他のプロジェクトは結構やってるらしいけど、Misskeyの場合(？)バグフィックスと機能追加が絶望的に相性が悪いことがままあるため、そんなことはしない方がいいと思っている）

[samunohito]

release(もしくはdevelop)のバグフィックスと並行してmasterへ機能を追加するのは破綻する

？
作ってもらったActionsはmasterをロックするようにしてもらったような

[tamaina]

release(もしくはdevelop)のバグフィックスと並行してmasterへ機能を追加するのは破綻する

？ 作ってもらったActionsはmasterをロックするようにしてもらったような

#12807 (comment) らへんのコメントを見たので

（あとロック未実装のActionsを試している時に間違ってmasterを更新したら面倒なことになったので念押しした）

[samunohito]

何が課題として残っているのか知りたい

• 本格導入するには、もっと手順を簡略化する必要がある…？　→手順書があれば解決する？
• そもそも導入の機運が低い　→issueのclose

[kakkokari-gtyih]

色々あって導入のタイミングがなかなか決まらないのが大きな原因な気がする

[kakkokari-gtyih]

（月初めだし、前回リリース以降CHANGELOGが変化するPRがまだ入っていないので導入するなら今がタイミング的に一番良さそうだとは思っている）

[syuilo]

やるか