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
SRE、開発、QAが協業して挑んだリリースプロセス改革@SRE Kaigi 2025
Search
Nealle
January 23, 2025
Programming
3
6.6k
SRE、開発、QAが協業して挑んだリリースプロセス改革@SRE Kaigi 2025
SRE Kaigi 2025
https://2025.srekaigi.net/
Nealle
January 23, 2025
Tweet
Share
More Decks by Nealle
See All by Nealle
ニーリーにおけるプロダクトエンジニア
nealle
0
100
プロダクト志向なエンジニアがもう一歩先の価値を目指すために意識したこと
nealle
0
110
事業KPIを基に価値の解像度を上げる
nealle
0
350
一人目PdMとして、まず"自分"をPMFさせることから考える
nealle
0
390
エンジニアが挑む、限界までの越境
nealle
1
780
ニーリーQAのこれまでとこれから
nealle
2
1.3k
データ分析で事業貢献するために
nealle
0
1.9k
SREチームのタスク優先度と向き合う Road to SRE NEXT@札幌
nealle
0
180
運用しながらリアーキテクチャ
nealle
0
720
Other Decks in Programming
See All in Programming
「ElixirでIoT!!」のこれまでとこれから
takasehideki
0
370
「Cursor/Devin全社導入の理想と現実」のその後
saitoryc
0
130
アンドパッドの Go 勉強会「 gopher 会」とその内容の紹介
andpad
0
260
PostgreSQLのRow Level SecurityをPHPのORMで扱う Eloquent vs Doctrine #phpcon #track2
77web
2
290
ドメインモデリングにおける抽象の役割、tagless-finalによるDSL構築、そして型安全な最適化
knih
11
2k
Systèmes distribués, pour le meilleur et pour le pire - BreizhCamp 2025 - Conférence
slecache
0
100
#kanrk08 / 公開版 PicoRubyとマイコンでの自作トレーニング計測装置を用いたワークアウトの理想と現実
bash0c7
1
250
なぜ適用するか、移行して理解するClean Architecture 〜構造を超えて設計を継承する〜 / Why Apply, Migrate and Understand Clean Architecture - Inherit Design Beyond Structure
seike460
PRO
1
650
Gleamという選択肢
comamoca
6
760
XSLTで作るBrainfuck処理系
makki_d
0
210
生成AIコーディングとの向き合い方、AIと共創するという考え方 / How to deal with generative AI coding and the concept of co-creating with AI
seike460
PRO
1
330
ASP.NETアプリケーションのモダナイズ インフラ編
tomokusaba
1
410
Featured
See All Featured
Understanding Cognitive Biases in Performance Measurement
bluesmoon
29
1.8k
Navigating Team Friction
lara
187
15k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
8
670
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
107
19k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
What's in a price? How to price your products and services
michaelherold
246
12k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
281
13k
Building Applications with DynamoDB
mza
95
6.5k
Scaling GitHub
holman
459
140k
Gamification - CAS2011
davidbonilla
81
5.3k
Facilitating Awesome Meetings
lara
54
6.4k
Become a Pro
speakerdeck
PRO
28
5.4k
Transcript
2025/01/26 SRE Kaigi 2025 株式会社ニーリー 宮後 啓介 @miya10kei NEALLE SRE、開発、QAが協業して挑んだ
リリースプロセス改革 1
2023年にニーリーにジョイン SREとしてサービスの信頼性やアジリティ向上の施策を実施。 最近はSRE業務のかたわら生成AIを用いた業務改善をしています。 以前は、SIerで業務システムのスクラッチ開発、Web系企業でメー ルサービスやフリマサービスなど複数のサービス開発やSRE業務を 担当。 2 自己紹介 @miya10kei 株式会社ニーリー
プラットフォーム開発G SREチーム リーダー Keisuke Miyaushiro 宮後 啓介
3 プロダクト紹介
複数のチームユニット 4 プロダクト開発組織の紹介 ※ 2024年12月時点 Nealle プロダクト統括本部 Growth/BizDev PdM エンジニア
QA デザイン 5名 SRE Platform Success Engineering Architecture Design エンジニア エンジニア エンジニア エンジニア デザイン 2名 6名 4名 1名 全チームユニット合計 PdM エンジニア QA デザイン 3名 32名 7名 5名 ・ ・ ・ Nealle全体の従業員数 約 200名 開発組織の従業員数 約 65名 ※ 業務委託/兼務を含む
目次 1|抱えていた課題 2|取り組み 3|現在の課題と今後の取り組み 4|まとめ 5
目次 1|抱えていた課題 2|取り組み 3|現在の課題と今後の取り組み 4|まとめ 6
7 1|抱えていた課題 デプロイ頻度の低さ 変更障害率の高さ
8 1|抱えていた課題 ~ デプロイ頻度 ~ 月に2〜5回ほどの頻度でしかデプロイできていない状態🥲
9 1|抱えていた課題 ~ 変更障害率 ~ デプロイすると40%は障害が発生していた状態🥲
10 プロダクトをグロースさせていく上で 高頻度に安定したリリースをしていくことは重要! 1|抱えていた課題
開発から運用まで含めたリリースプロセスの改革に着手! 11 1|抱えていた課題
目次 1|抱えていた課題 2|取り組み 3|現在の課題と今後の取り組み 4|まとめ 12
13 2|取り組み 開発 テスト リリース 運用 Feature環境の導入 開発DB複製の自動化 テストでの 本番データ利用
ゼロダウンタイム リリースの実現 DBマイグレーション のリハーサル リリーストグルの運用改善 パラレルテスト の導入
14 2|取り組み 〜 ゼロダウンタイムリリースの実現 〜 開発 テスト リリース 運用 Feature環境の導入
開発DB複製の自動化 テストでの 本番データ利用 ゼロダウンタイム リリースの実現 DBマイグレーション のリハーサル リリーストグルの運用改善 パラレルテスト の導入
▪ 課題 • 全てのリリースがダウンタイムを伴うものになっていた ◦ 頻度高くリリースができない ◦ 深夜作業となり負担が大きい ▪ 取り組み
• ゼロダウンタイムでのリリースを実現するために次の取り組みを実施し、ダウン タイムリリースとゼロダウンタイムリリースを選択できるようにした ◦ ゼロダウンタイムでリリースすための条件を整理 ◦ ゼロダウンタイムリリースの仕組みの構築 15 2|取り組み 〜 ゼロダウンタイムリリースの実現 〜
▪ ゼロダウンタイムでリリースするための条件を整理 • アプリケーション間の後方互換性が担保できていること • DBマイグレーションが伴わないこと ◦ ※ DBマイグレーションのリハーサルをおこなうことで一部緩和 16
2|取り組み 〜 ゼロダウンタイムリリースの実現 〜
▪ ゼロダウンタイムリリースの仕組みの構築 ▼ 既存のダウンタイムリリース developブランチに変更を溜め込み、リリースタイミングでstaging/masterブランチ に反映 17 2|取り組み 〜 ゼロダウンタイムリリースの実現
〜
▪ ゼロダウンタイムリリースの仕組みの構築 ▼ ゼロダウンタイムリリース stagingブランチに変更を溜め込むことでダウンタイムリリースと開発ラインを分離 18 2|取り組み 〜 ゼロダウンタイムリリースの実現 〜
19 2|取り組み 〜 DBマイグレーションのリハーサル 〜 開発 テスト リリース 運用 Feature環境の導入
開発DB複製の自動化 テストでの 本番データ利用 ゼロダウンタイム リリースの実現 DBマイグレーション のリハーサル リリーストグルの運用改善 パラレルテスト の導入
▪ 課題 • DBマイグレーションが必要なリリースが全てダウンタイムリリースとなっていた ◦ テーブルやレコードロックによるアプリケーションへの影響を気にしていた ▪ 取り組み • 事前に本番データを用いてDBマイグレーションを実行する仕組みを構築し、ロッ
ク時間の短いマイグレーションはゼロダウンタイムでのリリースを許容するよう にした 20 2|取り組み 〜 DBマイグレーションのリハーサル 〜
GitHub ActionsのWFから本番データに対してDBマイグレーションを実行できる仕組み を構築 21 2|取り組み 〜 DBマイグレーションのリハーサル 〜
テーブル毎のロック時間をSlackに通知し、ゼロダウンタイムでのリリースが可能かを 判断 22 2|取り組み 〜 DBマイグレーションのリハーサル 〜
23 2|取り組み 〜 Feature環境の導入 〜 開発 テスト リリース 運用 Feature環境の導入
開発DB複製の自動化 テストでの 本番データ利用 ゼロダウンタイム リリースの実現 DBマイグレーション のリハーサル リリーストグルの運用改善 パラレルテスト の導入
▪ 課題 • 開発環境へのマージ前に開発中のアプリケーションを複数人で同時に触ることが できない • クラウド環境でしか確認できない事象の検証に手間がかかる ▪ 取り組み •
Feature環境(=Pull Requestの単位で作成可能な専用環境)を作成する仕組みを 構築し、案件単位で並行開発しやすい環境を整備 24 2|取り組み 〜 Feature環境の導入 〜
25 2|取り組み 〜 Feature環境の導入 〜 Pull Requestへのラベル付与をトリガーに専用のFeature環境を構築 • 21時に自動削除することでコストを削減
Feature環境についての詳細はテックブログに載っているので是非ご覧ください! 26 2|取り組み 〜 Feature環境の導入 〜 https://nealle-dev.hatenablog.com/entry/2024/12/20/01 https://nealle-dev.hatenablog.com/entry/2024/04/01/120409
27 GitHub ActionsをトリガーにSlackで操作者に通知したい場合、Slackのマイキーワード にGitHubのユーザ名を登録することで簡単に通知することができます! ※ SlackのGitHubアプリでは多数の通知が届いてしまいノイズになってました💦 Tips|GitHub ActionsからSlack通知をするとき
28 2|取り組み 〜 開発DB複製の自動化 〜 開発 テスト リリース 運用 Feature環境の導入
開発DB複製の自動化 テストでの 本番データ利用 ゼロダウンタイム リリースの実現 DBマイグレーション のリハーサル リリーストグルの運用改善 パラレルテスト の導入
▪ 課題 • Feature環境はDBを開発環境と共有しており、スキーマやデータの更新が全体に 影響していた • 手動で開発環境のDBを複製していたが、設定や削除漏れなどが発生していた ◦ なにより手間がかかっていた、、、 ▪
取り組み • 開発DBの複製を自動化し、Feature環境と同様にPull Request単位で専用のDBを 利用可能にした 29 2|取り組み 〜 開発DB複製の自動化 〜
30 2|取り組み 〜 開発DB複製の自動化 〜 Pull Requestへのラベル付与をトリガーに開発環境のDBを複製する • 21時に自動停止、9時に自動起動することでコスト削減 •
Pull Requestのマージとクローズタイミングで自動削除し消し忘れ防止
31 2|取り組み 開発 テスト リリース 運用 Feature環境の導入 開発DB複製の自動化 テストでの 本番データ利用
ゼロダウンタイム リリースの実現 DBマイグレーション のリハーサル リリーストグルの運用改善 パラレルテスト の導入
▪ 課題 • 複雑な機能のテストデータの準備に時間がかかる ◦ 抜け漏れなども発生し、リリース後に不具合が発覚してしまう ◦ 本番データをそのままテストに利用するとデータ漏えいのリスクがある ▪ 取り組み
• テストに本番データを安全に利用できるように次の仕組みを構築 ◦ データの自動マスキング ◦ 外部との通信を遮断 ※ マスキングと通信遮断の2段階の防止策を設けることでデータ漏洩のリスク低減 32 2|取り組み - テストでの本番データ利用-
▪ データの自動マスキング Pull Requestへのラベル付与をトリガーに本番DBを複製し、自動でマスキング実施 33 2|取り組み - テストでの本番データ利用-
▪ 外部との通信を遮断 Network Firewallを用いて外部通信を制限することで、意図しないデータ転送を抑制 • Feature環境と同様にPRに特定ラベルを付与することで自動で構築される 34 2|取り組み - テストでの本番データ利用-
35 2|取り組み 〜 パラレルテストの導入〜 開発 テスト リリース 運用 Feature環境の導入 開発DB複製の自動化
テストでの 本番データ利用 ゼロダウンタイム リリースの実現 DBマイグレーション のリハーサル リリーストグルの運用改善 パラレルテスト の導入
▪ 課題 • 開発者によるスクリプトテストとQAによる探索的テストをシリアルにおこなっ ていたことでリリースまでのサイクルタイム増加の一つの要因となっていた ▪ 取り組み • Feature環境を利用し、パラレルテスト(=開発者によるスクリプトテストとQAに よる探索的テストの並列実施)をおこなうプロセスに変更
◦ テストがパラレルになることでサイクルタイムを短縮できる ◦ Pull Requestの段階でQAからバグのフィードバックを得られる ※ パラレルテストは弊社の造語です 36 2|取り組み 〜 パラレルテストの導入〜
37 2|取り組み 〜 パラレルテストの導入〜
38 2|取り組み ~ リリーストグルの運用改善 ~ 開発 テスト リリース 運用 Feature環境の導入
開発DB複製の自動化 テストでの 本番データ利用 ゼロダウンタイム リリースの実現 DBマイグレーション のリハーサル リリーストグルの運用改善 パラレルテスト の導入
▪ リリーストグル フィーチャーフラグの一種。コードのデプロイと機能リリースをフラグのOFF/ONで 分離することでブランチワークの複雑化の回避とリードタイムの短縮を図る。 ▪ 課題 • 各環境(開発、ステージング、本番)のトグルの設定値を横断的に確認できない • 不要になったトグルの削除ができておらず、コードが複雑化してしまっている
• ローカル環境への各環境のトグル状態の取り込みが大変、、、 ▪ 取り組み • 横断的にトグルの状態を確認できるダッシュボードの整備 • 不要になったトグルを通知する仕組みを構築 • 特定環境のトグル状態を取り込むスクリプトを作成 39 2|取り組み ~ リリーストグルの運用改善 ~
▪ 横断的にトグルの状態を確認できるダッシュボードの整備 40 2|取り組み ~ リリーストグルの運用改善 ~
▪ 横断的にトグルの状態を確認できるダッシュボードの整備 41 2|取り組み ~ リリーストグルの運用改善 ~
▪ 不要になったトグルを通知する仕組みを構築 一定期間更新のないトグルの数が一定数を超えた場合に、開発者にSlack通知すること で削除忘れを防止 42 2|取り組み ~ リリーストグルの運用改善 ~
▪ 特定環境のトグル状態を取り込むスクリプトを作成 43 2|取り組み ~ リリーストグルの運用改善 ~
44 2|取り組み 開発 テスト リリース 運用 Feature環境の導入 開発DB複製の自動化 テストでの 本番データ利用
ゼロダウンタイム リリースの実現 DBマイグレーション のリハーサル リリーストグルの運用改善 パラレルテスト の導入
毎日複数回リリースできる状態まで大きく改善 ! 45 2|取り組み - デプロイ頻度改善の効果 -
10%程度まで低減することができ大きく改善! 46 2|取り組み - 変更障害率改善の効果 -
目次 1|抱えていた課題 2|取り組み 3|現在の課題と今後の取り組み 4|まとめ 47
48 3|現在の課題と今後の取り組み ▪ 課題 1. リリースの相乗り待ちが発生してしまっている ◦ stagingブランチに変更を溜めてからリリースしているため、複数チームの 変更がリリース可能な状態になるのを待つ必要がある 2.
開発プロセスにおける開発者の負担が大きい ◦ 案件Doc作成、実装、テスト設計・実施、リリースなど多くの作業を担って いる
49 3|現在の課題と今後の取り組み ▪ 今後の取り組み 1. リリースの相乗り待ちが発生してしまっている → トランクベース開発に移行し、直接maserブランチへマージ/リリースして いくことで相乗り待ちをなくしていく 2. 開発プロセスにおいて開発者の負担が大きい
→ テスト設計、スクリプトテストの実施をQAが担うことで開発者の負担の低 減を図る
目次 1|抱えていた課題 2|取り組み 3|現在の課題と今後の取り組み 4|まとめ 50
• 高頻度で安定したリリースを実現するまでの課題と取り組みを紹介 • リリースに至るまでのプロセス全体を見て、課題を解決していくことが大きな効 果につながった • そのためにも、SRE、開発、QAといったプロセスに関わる複数のチームが協業 して取り組むことが重要 51 4|まとめ
ニーリー採用情報など
Thank you 53