定期リリースの導入

noteで定期リリースを導入した話です。

Transcript

1. 定期リリースの導入 2022/10/21 hiroki_tanaka
2. 【テーマ】 noteで 1日1回の定期リリースを導入する
3. 現状の随時リリースのメリット・デメリット - 現在、特定のブロックタイム以外はいつでも誰でも本番リリース可能になっていま す。 - 【メリット】 - noteのバリューである「素早く試す」の観点に合っている。 - 文言変更やスタイル変更などの軽微な修正を即リリースし、ユーザに価値提供できる。 - 【デメリット・問題点】 - リリース時に品質を担保するプロセスが確立されていないため、障害に繋がりやすい。 - 障害発生時に障害がどのリリースによって引き起こされたかの特定が難しい。
4. 現状の随時リリースのメリット・デメリット - 現在、特定のブロックタイム以外はいつでも誰でも本番リリース可能になっていま す。 - 【メリット】 - noteのバリューである「素早く試す」の観点に合っている。 - 文言変更やスタイル変更などの軽微な修正を即リリースし、ユーザに価値提供できる。 - 【デメリット・問題点】 - リリース時に品質を担保するプロセスが確立されていないため、障害に繋がりやすい。 - 障害発生時に障害がどのリリースによって引き起こされたかの特定が難しい。 プロダクト・組織が大きくなるにつれてデメリットが顕在化
5. そうだ！！ 日次での定期リリースを 試してみよう！！
6. 定期リリースのやり方 - 9~14時をdevelopマージの期間として、1日1度15時に定期リリースを実施します。 - リリース前に検証フェーズを追加することでリリース前の品質チェックを強化出来る。 - 障害が発生した際にどのリリース起因かの特定が容易になり、復旧対応を早めることが出来る。 - 実装者の知らない間にリリースされていたという事態を避けることが出来る。 - ただ、15~18時はこれまで通り随時リリースをOKとします。 - 文言変更やスタイル変更などの軽微な修正を即リリースし、ユーザへの素早い価値提供は継続出 来る。
7. 定期リリースのやり方 - 9~14時をdevelopマージの期間として、1日1度15時に定期リリースを実施します。 - リリース前に検証フェーズを追加することでリリース前の品質チェックを強化出来る。 - 障害が発生した際にどのリリース起因かの特定が容易になり、復旧対応を早めることが出来る。 - 実装者の知らない間にリリースされていたという事態を避けることが出来る。 - ただ、15~18時はこれまで通り随時リリースをOKとします。 - 文言変更やスタイル変更などの軽微な修正を即リリースし、ユーザへの素早い価値提供は継続出 来る。 随時リリースと定期リリースのハイブリットを試験運用！
8. 新リリースフローの全体図
9. 新リリースフローの全体図
10. 新リリースフローの時間帯ごとの詳細：9:00~14:00 - 各feature PRのdevelopマージ時間。 - 各チーム・各開発者がその日の定期リリースでリリースしたい PRがある場合はこの時間に develop へのマージを行ってください。 - hotfixリリースは原則禁止。 - 原則hotfixリリースは禁止ですが、障害が発生してしまった場合は例外的に hotfixリリースを行い、 その際のリリース担当者は QAチームが担当し、Zoom/ハドルを繋ぎながらダブルチェックしながら 作業を進める。 - hotfixリリース時は該当の修正 PRのみをリリースするため、それまでに developにマージしたPRは 一度Revertさせて頂く。(hotfixリリースが終わり次第、再度 RevertのRevertを行う。)
11. 新リリースフローの全体図
12. 新リリースフローの時間帯ごとの詳細：14:01~15:00 - リリース担当者がdevelopブランチを検証環境にリリースし、E2Eテストのmablでの リリース前検証を行います。 - コミッターへのメンションも行い、検証環境での手動検証を行うように依頼します。 - mablがflakyケースなどで失敗した場合は該当箇所を画面から手動で動作確認します。 - 手動検証でも失敗した場合は、その日の定期リリースは取り止めます。 - developはRevertせず、改めて翌日にリリース PRを作成してリリースを行います。 - リリース前検証の確認が取れ次第、server側→front側の順にリリースします。 - リリース後はこれまで通り、コミッターにメンションし、リリース後の確認依頼及びエラーログ・ Sentry の監視を依頼します。
13. 新リリースフローの全体図
14. 新リリースフローの時間帯ごとの詳細：15:01~18:00 - 随時リリース可能時間帯。 - 各チームで即時リリースしたいケースがあると思うので、この時間はこれまで通りの随時リリースを 行っていただいて大丈夫です。 - 定期リリースと異なり、この時間の各リリースに関して QAチームはリリース担当者としてリリース前 検証作業などは行いません。 - そのため、各チーム・各開発者が責任を持ってリリースをお願い致します。 - 注意点：その日中にリリースしない PR(=明日の定期リリースに乗せたい PR)の場合は、この時間の developマージは避けてください。
15. 新リリースフローの時間帯ごとの詳細：18:01~翌日8:59 - developマージ禁止。 - 18時以降は原則、developマージ(及びhotfixデプロイ)は禁止です。 - 例外的にdevelopマージ(及びhotfixデプロイ)を行いたい場合は各チームのリーダと相談・合意を 取った上で実施してください。
16. 想定Q&A
17. front側を先にリリースしたい場合は？ - front側から先にリリースしたい場合は、事前にリリース担当者に連絡してください。 - 基本的にserver側からリリース作業を行いますが、内容によって臨機応変に対応致します。
18. RubyバージョンUPや巨大機能をリリースしたい場合は？ - リリースカレンダーに追加し全体周知の上で、他のPRのdevelopマージをブロックし てください。 - 該当機能のみのリリースであることが確認できた上で定期リリースと同様の検証を行い、リリースを 行います。
19. まとめ
20. まとめと今後 - noteでは初の試みとなる1日1便の定期リリースの試験運用を始めます。 - 定期リリースにするだけでなく、リリース前の検証フェーズの導入も併せて行います。 - 開発者の方は「ブランチのdevelopマージ可能時間が9~14時で15時に本番リリースされる。そこか ら18時までは各チームでの随時リリースが可能。」 と覚えて頂ければ大丈夫です。 - 導入後は効果測定を行い、随時アップデートを行っていく想定です。 - 測定項目としてはデリバリーされた PR数の増減と本番障害発生回数やリリース後の Revert回数を 考えています。 - 品質向上効果が得られなかった場合は元のフローに戻すことも検討します。
21. ご清聴ありがとうございました