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
150
定期リリースの導入
noteで定期リリースを導入した話です。
Hiroki Tanaka
October 21, 2022
Tweet
Share
More Decks by Hiroki Tanaka
See All by Hiroki Tanaka
機能QA会のすゝめ
hiroki_tanaka
0
210
noteの品質課題に立ち上げ直後のQAチームが挑んだ軌跡
hiroki_tanaka
1
1.4k
note初のBug Bashを やってみた
hiroki_tanaka
1
1.4k
コロナ禍の1年間でAWSの資格を 3つ取得した話
hiroki_tanaka
0
360
Rubocop対応のすゝめ
hiroki_tanaka
0
53
Gotanda.rb#48 ECS on Fargateでのハマりポイント
hiroki_tanaka
1
320
Gotanda.rb#47 Mailgun3分クッキング
hiroki_tanaka
1
7k
Gotanda.rb#46 権限管理のつらみとPundit
hiroki_tanaka
1
7.1k
Other Decks in Technology
See All in Technology
スケールアップ企業のQA組織のバリューを最大限に引き出すための取り組み
tarappo
4
910
Keynote - KCD Brazil - Platform Engineering on K8s (portuguese)
salaboy
0
120
AIエージェントキャッチアップと論文リサーチ
os1ma
6
1.2k
コンソールで学ぶ!AWS CodePipelineの機能とオプション
umekou
2
110
Restarting_SRE_Road_to_SRENext_.pdf
_awache
0
160
ドメインイベントを活用したPHPコードのリファクタリング
kajitack
2
1.1k
Agile TPIを活用した品質改善事例
tomasagi
0
290
数百台のオンプレミスのサーバーをEKSに移行した話
yukiteraoka
0
640
Tirez profit de Messenger pour améliorer votre architecture
tucksaun
1
130
年末調整プロダクトの内部品質改善活動について
kaomi_wombat
0
200
Cline、めっちゃ便利、お金が飛ぶ💸
iwamot
19
18k
ルートユーザーの活用と管理を徹底的に深掘る
yuobayashi
6
720
Featured
See All Featured
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
11
610
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
356
30k
The World Runs on Bad Software
bkeepers
PRO
67
11k
Code Review Best Practice
trishagee
67
18k
What's in a price? How to price your products and services
michaelherold
245
12k
Why Our Code Smells
bkeepers
PRO
336
57k
[RailsConf 2023] Rails as a piece of cake
palkan
53
5.4k
It's Worth the Effort
3n
184
28k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
45
9.5k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
28
2k
How to Ace a Technical Interview
jacobian
276
23k
The Pragmatic Product Professional
lauravandoore
33
6.5k
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回数を 考えています。 - 品質向上効果が得られなかった場合は元のフローに戻すことも検討します。
ご清聴ありがとうございました