Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
定期リリースの導入
Search
Hiroki Tanaka
October 21, 2022
Technology
0
180
定期リリースの導入
noteで定期リリースを導入した話です。
Hiroki Tanaka
October 21, 2022
Tweet
Share
More Decks by Hiroki Tanaka
See All by Hiroki Tanaka
機能QA会のすゝめ
hiroki_tanaka
0
250
noteの品質課題に立ち上げ直後のQAチームが挑んだ軌跡
hiroki_tanaka
1
1.5k
note初のBug Bashを やってみた
hiroki_tanaka
1
1.5k
コロナ禍の1年間でAWSの資格を 3つ取得した話
hiroki_tanaka
0
400
Rubocop対応のすゝめ
hiroki_tanaka
0
72
Gotanda.rb#48 ECS on Fargateでのハマりポイント
hiroki_tanaka
1
360
Gotanda.rb#47 Mailgun3分クッキング
hiroki_tanaka
1
7.2k
Gotanda.rb#46 権限管理のつらみとPundit
hiroki_tanaka
1
7.3k
Other Decks in Technology
See All in Technology
react-callを使ってダイヤログをいろんなとこで再利用しよう!
shinaps
1
240
OCI Oracle Database Services新機能アップデート(2025/06-2025/08)
oracle4engineer
PRO
0
140
ブロックテーマ時代における、テーマの CSS について考える Toro_Unit / 2025.09.13 @ Shinshu WordPress Meetup
torounit
0
120
サラリーマンの小遣いで作るtoCサービス - Cloudflare Workersでスケールする開発戦略
shinaps
2
440
KotlinConf 2025_イベントレポート
sony
1
130
Language Update: Java
skrb
2
300
今!ソフトウェアエンジニアがハードウェアに手を出すには
mackee
12
4.8k
企業の生成AIガバナンスにおけるエージェントとセキュリティ
lycorptech_jp
PRO
2
160
Platform開発が先行する Platform Engineeringの違和感
kintotechdev
4
570
生成AI時代のデータ基盤設計〜ペースレイヤリングで実現する高速開発と持続性〜 / Levtech Meetup_Session_2
sansan_randd
1
150
「何となくテストする」を卒業するためにプロダクトが動く仕組みを理解しよう
kawabeaver
0
410
人工衛星のファームウェアをRustで書く理由
koba789
15
7.9k
Featured
See All Featured
VelocityConf: Rendering Performance Case Studies
addyosmani
332
24k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
27k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
4k
Code Reviewing Like a Champion
maltzj
525
40k
Imperfection Machines: The Place of Print at Facebook
scottboms
268
13k
Documentation Writing (for coders)
carmenintech
74
5k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
31
2.5k
The World Runs on Bad Software
bkeepers
PRO
70
11k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
Reflections from 52 weeks, 52 projects
jeffersonlam
352
21k
Code Review Best Practice
trishagee
70
19k
Building Better People: How to give real-time feedback that sticks.
wjessup
368
19k
Transcript
定期リリースの導入 2022/10/21 hiroki_tanaka
【テーマ】 noteで 1日1回の定期リリースを導入する
現状の随時リリースのメリット・デメリット - 現在、特定のブロックタイム以外はいつでも誰でも本番リリース可能になっていま す。 - 【メリット】 - noteのバリューである「素早く試す」の観点に合っている。 - 文言変更やスタイル変更などの軽微な修正を即リリースし、ユーザに価値提供できる。
- 【デメリット・問題点】 - リリース時に品質を担保するプロセスが確立されていないため、障害に繋がりやすい。 - 障害発生時に障害がどのリリースによって引き起こされたかの特定が難しい。
現状の随時リリースのメリット・デメリット - 現在、特定のブロックタイム以外はいつでも誰でも本番リリース可能になっていま す。 - 【メリット】 - noteのバリューである「素早く試す」の観点に合っている。 - 文言変更やスタイル変更などの軽微な修正を即リリースし、ユーザに価値提供できる。
- 【デメリット・問題点】 - リリース時に品質を担保するプロセスが確立されていないため、障害に繋がりやすい。 - 障害発生時に障害がどのリリースによって引き起こされたかの特定が難しい。 プロダクト・組織が大きくなるにつれてデメリットが顕在化
そうだ!! 日次での定期リリースを 試してみよう!!
定期リリースのやり方 - 9~14時をdevelopマージの期間として、1日1度15時に定期リリースを実施します。 - リリース前に検証フェーズを追加することでリリース前の品質チェックを強化出来る。 - 障害が発生した際にどのリリース起因かの特定が容易になり、復旧対応を早めることが出来る。 - 実装者の知らない間にリリースされていたという事態を避けることが出来る。 -
ただ、15~18時はこれまで通り随時リリースをOKとします。 - 文言変更やスタイル変更などの軽微な修正を即リリースし、ユーザへの素早い価値提供は継続出 来る。
定期リリースのやり方 - 9~14時をdevelopマージの期間として、1日1度15時に定期リリースを実施します。 - リリース前に検証フェーズを追加することでリリース前の品質チェックを強化出来る。 - 障害が発生した際にどのリリース起因かの特定が容易になり、復旧対応を早めることが出来る。 - 実装者の知らない間にリリースされていたという事態を避けることが出来る。 -
ただ、15~18時はこれまで通り随時リリースをOKとします。 - 文言変更やスタイル変更などの軽微な修正を即リリースし、ユーザへの素早い価値提供は継続出 来る。 随時リリースと定期リリースのハイブリットを試験運用!
新リリースフローの全体図
新リリースフローの全体図
新リリースフローの時間帯ごとの詳細:9:00~14:00 - 各feature PRのdevelopマージ時間。 - 各チーム・各開発者がその日の定期リリースでリリースしたい PRがある場合はこの時間に develop へのマージを行ってください。 -
hotfixリリースは原則禁止。 - 原則hotfixリリースは禁止ですが、障害が発生してしまった場合は例外的に hotfixリリースを行い、 その際のリリース担当者は QAチームが担当し、Zoom/ハドルを繋ぎながらダブルチェックしながら 作業を進める。 - hotfixリリース時は該当の修正 PRのみをリリースするため、それまでに developにマージしたPRは 一度Revertさせて頂く。(hotfixリリースが終わり次第、再度 RevertのRevertを行う。)
新リリースフローの全体図
新リリースフローの時間帯ごとの詳細:14:01~15:00 - リリース担当者がdevelopブランチを検証環境にリリースし、E2Eテストのmablでの リリース前検証を行います。 - コミッターへのメンションも行い、検証環境での手動検証を行うように依頼します。 - mablがflakyケースなどで失敗した場合は該当箇所を画面から手動で動作確認します。 - 手動検証でも失敗した場合は、その日の定期リリースは取り止めます。
- developはRevertせず、改めて翌日にリリース PRを作成してリリースを行います。 - リリース前検証の確認が取れ次第、server側→front側の順にリリースします。 - リリース後はこれまで通り、コミッターにメンションし、リリース後の確認依頼及びエラーログ・ Sentry の監視を依頼します。
新リリースフローの全体図
新リリースフローの時間帯ごとの詳細:15:01~18:00 - 随時リリース可能時間帯。 - 各チームで即時リリースしたいケースがあると思うので、この時間はこれまで通りの随時リリースを 行っていただいて大丈夫です。 - 定期リリースと異なり、この時間の各リリースに関して QAチームはリリース担当者としてリリース前 検証作業などは行いません。
- そのため、各チーム・各開発者が責任を持ってリリースをお願い致します。 - 注意点:その日中にリリースしない PR(=明日の定期リリースに乗せたい PR)の場合は、この時間の developマージは避けてください。
新リリースフローの時間帯ごとの詳細:18:01~翌日8:59 - developマージ禁止。 - 18時以降は原則、developマージ(及びhotfixデプロイ)は禁止です。 - 例外的にdevelopマージ(及びhotfixデプロイ)を行いたい場合は各チームのリーダと相談・合意を 取った上で実施してください。
想定Q&A
front側を先にリリースしたい場合は? - front側から先にリリースしたい場合は、事前にリリース担当者に連絡してください。 - 基本的にserver側からリリース作業を行いますが、内容によって臨機応変に対応致します。
RubyバージョンUPや巨大機能をリリースしたい場合は? - リリースカレンダーに追加し全体周知の上で、他のPRのdevelopマージをブロックし てください。 - 該当機能のみのリリースであることが確認できた上で定期リリースと同様の検証を行い、リリースを 行います。
まとめ
まとめと今後 - noteでは初の試みとなる1日1便の定期リリースの試験運用を始めます。 - 定期リリースにするだけでなく、リリース前の検証フェーズの導入も併せて行います。 - 開発者の方は「ブランチのdevelopマージ可能時間が9~14時で15時に本番リリースされる。そこか ら18時までは各チームでの随時リリースが可能。」 と覚えて頂ければ大丈夫です。 -
導入後は効果測定を行い、随時アップデートを行っていく想定です。 - 測定項目としてはデリバリーされた PR数の増減と本番障害発生回数やリリース後の Revert回数を 考えています。 - 品質向上効果が得られなかった場合は元のフローに戻すことも検討します。
ご清聴ありがとうございました