Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

リリース運用の再考 #12807

Closed
samunohito opened this issue Dec 26, 2023 · 97 comments · Fixed by #13075
Closed

リリース運用の再考 #12807

samunohito opened this issue Dec 26, 2023 · 97 comments · Fixed by #13075
Assignees
@tamaina
Labels
🛠️Dev Development of Misskey itself

Comments

@samunohito
Copy link
Member

samunohito commented Dec 26, 2023 •
edited
Loading

Summary

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

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

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

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

Purpose

  • リリース時の負荷が減る
  • 確認点が明確になることでバグを取り除きやすくなる（品質が上がる）
  • バグフィクスをリリースしやすくなりサーバ管理者各位・ユーザ各位にとってやさしい
@samunohito samunohito added the 🛠️Dev Development of Misskey itself label Dec 26, 2023
@samunohito
Copy link
Member Author

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

@syuilo syuilo pinned this issue Dec 26, 2023
@syuilo
Copy link
Member

syuilo commented Dec 26, 2023

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

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

@kakkokari-gtyih
Copy link
Contributor

kakkokari-gtyih commented Dec 26, 2023 •
edited
Loading

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

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

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

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

@syuilo
Copy link
Member

syuilo commented Dec 26, 2023

🆒

@samunohito
Copy link
Member Author

さすがすぎる

@kakkokari-gtyih

This comment was marked as off-topic.

Sign in to view
@samunohito

This comment was marked as off-topic.

Sign in to view
@syuilo
Copy link
Member

syuilo commented Dec 26, 2023

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

@samunohito
Copy link
Member Author

samunohito commented Dec 26, 2023 •
edited
Loading

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

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

@samunohito
Copy link
Member Author

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

@syuilo
Copy link
Member

syuilo commented Dec 26, 2023

前者にするかしら

@samunohito
Copy link
Member Author

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

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

@tamaina

This comment has been minimized.

Sign in to view
@syuilo
Copy link
Member

syuilo commented Dec 26, 2023

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

@tamaina
Copy link
Contributor

tamaina commented Dec 26, 2023

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

@tamaina
Copy link
Contributor

tamaina commented Dec 26, 2023

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

@syuilo
Copy link
Member

syuilo commented Dec 26, 2023

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

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

@syuilo
Copy link
Member

syuilo commented Dec 26, 2023

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

@samunohito
Copy link
Member Author

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

@anatawa12
Copy link
Member

anatawa12 commented Dec 26, 2023 •
edited
Loading

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

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

@kakkokari-gtyih
Copy link
Contributor

Misskey Hubの更新なども含めて

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

@kakkokari-gtyih kakkokari-gtyih mentioned this issue Dec 26, 2023
Closed
@tamaina
Copy link
Contributor

tamaina commented Dec 26, 2023 •
edited
Loading

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

@kakkokari-gtyih kakkokari-gtyih mentioned this issue Dec 26, 2023
Closed
1 task
@tamaina tamaina mentioned this issue Dec 26, 2023
Closed
@samunohito
Copy link
Member Author

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

@anatawa12
Copy link
Member

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

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

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

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

@tai-cha
Copy link
Contributor

tai-cha commented Dec 27, 2023 •
edited
Loading

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

@tamaina
Copy link
Contributor

tamaina commented Jan 24, 2024

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

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

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

@tamaina
Copy link
Contributor

tamaina commented Jan 24, 2024

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

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

@FineArchs
Copy link
Contributor

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

@FineArchs
Copy link
Contributor

FineArchs commented Jan 24, 2024 •
edited
Loading

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

@syuilo
Copy link
Member

syuilo commented Jan 24, 2024

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

新規ドキュメント 1 2024_01_24_04_14_24 0

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

@tamaina
Copy link
Contributor

tamaina commented Jan 24, 2024

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

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

workflow dispatchで全自動で行われる

@syuilo
Copy link
Member

syuilo commented Jan 24, 2024

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

@tamaina
Copy link
Contributor

tamaina commented Jan 24, 2024 •
edited
Loading

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

@samunohito
Copy link
Member Author

やりたい

@syuilo
Copy link
Member

syuilo commented Mar 2, 2024

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

@tamaina
Copy link
Contributor

tamaina commented Mar 2, 2024

@tamaina
Copy link
Contributor

tamaina commented Mar 2, 2024

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

@syuilo
Copy link
Member

syuilo commented Mar 2, 2024

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

@tamaina
Copy link
Contributor

tamaina commented Mar 2, 2024

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
Copy link
Contributor

tamaina commented Mar 2, 2024

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

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

@tamaina
Copy link
Contributor

tamaina commented Mar 2, 2024 •
edited
Loading

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

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

@tamaina
Copy link
Contributor

tamaina commented Mar 2, 2024

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

@tamaina
Copy link
Contributor

tamaina commented Mar 2, 2024 •
edited
Loading

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

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

@samunohito
Copy link
Member Author

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

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

@tamaina
Copy link
Contributor

tamaina commented Mar 2, 2024 •
edited
Loading

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

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

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

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

@samunohito
Copy link
Member Author

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

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

@kakkokari-gtyih
Copy link
Contributor

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

@kakkokari-gtyih
Copy link
Contributor

kakkokari-gtyih commented Mar 4, 2024 •
edited
Loading

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

@syuilo
Copy link
Member

syuilo commented Mar 4, 2024

やるか

@samunohito samunohito unpinned this issue Mar 29, 2024
@tamaina tamaina mentioned this issue Jun 3, 2024
Merged
5 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@tamaina tamaina

Labels
🛠️Dev Development of Misskey itself
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

chore: Automated release misskey-dev/misskey
chore: Automated release tamaina/misskey
9 participants
@syuilo @tamaina @anatawa12 @tachibana51 @tai-cha @samunohito @Sayamame-beans @kakkokari-gtyih @FineArchs