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
190
定期リリースの導入
noteで定期リリースを導入した話です。
Hiroki Tanaka
October 21, 2022
Tweet
Share
More Decks by Hiroki Tanaka
See All by Hiroki Tanaka
機能QA会のすゝめ
hiroki_tanaka
0
260
noteの品質課題に立ち上げ直後のQAチームが挑んだ軌跡
hiroki_tanaka
1
1.5k
note初のBug Bashを やってみた
hiroki_tanaka
1
1.5k
コロナ禍の1年間でAWSの資格を 3つ取得した話
hiroki_tanaka
0
410
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
プロポーザルのコツ ~ Kaigi on Rails 2025 初参加で3名の登壇を実現 ~
naro143
1
250
Claude Code Subagents 再入門 ~cc-sddの実装で学んだこと~
gotalab555
10
14k
Introduction to Bill One Development Engineer
sansan33
PRO
0
300
ユーザーの声とAI検証で進める、プロダクトディスカバリー
sansantech
PRO
1
140
リセラー企業のテクサポ担当が考える、生成 AI 時代のトラブルシュート 2025
kazzpapa3
1
350
PHPからはじめるコンピュータアーキテクチャ / From Scripts to Silicon: A Journey Through the Layers of Computing Hiroshima 2025 Edition
tomzoh
0
140
名刺メーカーDevグループ 紹介資料
sansan33
PRO
0
930
プロダクトのコードから見るGoによるデザインパターンの実践 #go_night_talk
bengo4com
1
2.6k
防災デジタル分野での官民共創の取り組み (2)DIT/CCとD-CERTについて
ditccsugii
0
300
OCI Network Firewall 概要
oracle4engineer
PRO
2
7.9k
All About Sansan – for New Global Engineers
sansan33
PRO
1
1.2k
Git in Team
kawaguti
PRO
3
380
Featured
See All Featured
The Pragmatic Product Professional
lauravandoore
36
6.9k
For a Future-Friendly Web
brad_frost
180
10k
Why You Should Never Use an ORM
jnunemaker
PRO
59
9.6k
Intergalactic Javascript Robots from Outer Space
tanoku
273
27k
Java REST API Framework Comparison - PWX 2021
mraible
34
8.9k
Fireside Chat
paigeccino
40
3.7k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
32
1.6k
Into the Great Unknown - MozCon
thekraken
40
2.1k
Become a Pro
speakerdeck
PRO
29
5.6k
Learning to Love Humans: Emotional Interface Design
aarron
274
41k
Building Adaptive Systems
keathley
44
2.8k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
33
2.3k
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回数を 考えています。 - 品質向上効果が得られなかった場合は元のフローに戻すことも検討します。
ご清聴ありがとうございました