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
160
定期リリースの導入
noteで定期リリースを導入した話です。
Hiroki Tanaka
October 21, 2022
Tweet
Share
More Decks by Hiroki Tanaka
See All by Hiroki Tanaka
機能QA会のすゝめ
hiroki_tanaka
0
230
noteの品質課題に立ち上げ直後のQAチームが挑んだ軌跡
hiroki_tanaka
1
1.4k
note初のBug Bashを やってみた
hiroki_tanaka
1
1.4k
コロナ禍の1年間でAWSの資格を 3つ取得した話
hiroki_tanaka
0
370
Rubocop対応のすゝめ
hiroki_tanaka
0
58
Gotanda.rb#48 ECS on Fargateでのハマりポイント
hiroki_tanaka
1
330
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
他チームへ越境したら、生データ提供ソリューションのクエリ費用95%削減へ繋がった話 / Cross-Team Impact: 95% Off Raw Data Query Costs
yamamotoyuta
0
230
セキュリティSaaS企業が実践するCursor運用ルールと知見 / How a Security SaaS Company Runs Cursor: Rules & Insights
tetsuzawa
0
220
テストを実施する前に考えるべきテストの話 / Thinking About Testing Before You Test
nihonbuson
PRO
13
2k
Devin&Cursor、それぞれの「本質」から導く最適ユースケース戦略
empitsu
8
2.4k
Eight Engineering Unit 紹介資料
sansan33
PRO
0
3.2k
名刺メーカーDevグループ 紹介資料
sansan33
PRO
0
740
AIオンボーディングとAIプロセスマイニング
nrryuya
5
1.3k
2025advance01
minamizaki
0
130
KMP導⼊において、マネジャーとして考えた事
sansantech
PRO
1
210
Digitization部 紹介資料
sansan33
PRO
1
3.8k
会社紹介資料 / Sansan Company Profile
sansan33
PRO
6
360k
Cloud Run を解剖して コンテナ監視を考える / Breaking Down Cloud Run to Rethink Container Monitoring
aoto
PRO
0
110
Featured
See All Featured
The Art of Programming - Codeland 2020
erikaheidi
54
13k
Building a Modern Day E-commerce SEO Strategy
aleyda
40
7.3k
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
For a Future-Friendly Web
brad_frost
178
9.7k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
233
17k
Build your cross-platform service in a week with App Engine
jlugia
231
18k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
30
2.4k
Testing 201, or: Great Expectations
jmmastey
42
7.5k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
25
2.8k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
45
9.6k
Art, The Web, and Tiny UX
lynnandtonic
298
21k
StorybookのUI Testing Handbookを読んだ
zakiyama
30
5.8k
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回数を 考えています。 - 品質向上効果が得られなかった場合は元のフローに戻すことも検討します。
ご清聴ありがとうございました