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
170
定期リリースの導入
noteで定期リリースを導入した話です。
Hiroki Tanaka
October 21, 2022
Tweet
Share
More Decks by Hiroki Tanaka
See All by Hiroki Tanaka
機能QA会のすゝめ
hiroki_tanaka
0
240
noteの品質課題に立ち上げ直後のQAチームが挑んだ軌跡
hiroki_tanaka
1
1.5k
note初のBug Bashを やってみた
hiroki_tanaka
1
1.5k
コロナ禍の1年間でAWSの資格を 3つ取得した話
hiroki_tanaka
0
380
Rubocop対応のすゝめ
hiroki_tanaka
0
66
Gotanda.rb#48 ECS on Fargateでのハマりポイント
hiroki_tanaka
1
340
Gotanda.rb#47 Mailgun3分クッキング
hiroki_tanaka
1
7.1k
Gotanda.rb#46 権限管理のつらみとPundit
hiroki_tanaka
1
7.2k
Other Decks in Technology
See All in Technology
Definition of Done
kawaguti
PRO
6
470
Agentic DevOps時代の生存戦略
kkamegawa
0
1.1k
Agentic Workflowという選択肢を考える
tkikuchi1002
1
420
Liquid Glass革新とSwiftUI/UIKit進化
fumiyasac0921
0
150
BrainPadプログラミングコンテスト記念LT会2025_社内イベント&問題解説
brainpadpr
0
160
変化する開発、進化する体系時代に適応するソフトウェアエンジニアの知識と考え方(JaSST'25 Kansai)
mizunori
0
160
あなたの声を届けよう! 女性エンジニア登壇の意義とアウトプット実践ガイド #wttjp / Call for Your Voice
kondoyuko
2
250
エンジニア向け技術スタック情報
kauche
0
110
Create a Rails8 responsive app with Gemini and RubyLLM
palladius
0
140
AWS Summit Japan 2025 Community Stage - App workflow automation by AWS Step Functions
matsuihidetoshi
1
150
“社内”だけで完結していた私が、AWS Community Builder になるまで
nagisa53
1
250
2年でここまで成長!AWSで育てたAI Slack botの軌跡
iwamot
PRO
2
490
Featured
See All Featured
The Invisible Side of Design
smashingmag
299
51k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
228
22k
Docker and Python
trallard
44
3.4k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
Become a Pro
speakerdeck
PRO
28
5.4k
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
Fireside Chat
paigeccino
37
3.5k
Rails Girls Zürich Keynote
gr2m
94
14k
Build The Right Thing And Hit Your Dates
maggiecrowley
36
2.8k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
53
2.8k
Bash Introduction
62gerente
614
210k
Faster Mobile Websites
deanohume
307
31k
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回数を 考えています。 - 品質向上効果が得られなかった場合は元のフローに戻すことも検討します。
ご清聴ありがとうございました