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
“いい感じ“な定量評価を求めて - Four Keysとアウトカムの間の探求 -
nealle
1
6.1k
ニーリーにおけるプロダクトエンジニア
nealle
0
750
プロダクト志向なエンジニアがもう一歩先の価値を目指すために意識したこと
nealle
0
120
事業KPIを基に価値の解像度を上げる
nealle
0
360
一人目PdMとして、まず"自分"をPMFさせることから考える
nealle
0
400
エンジニアが挑む、限界までの越境
nealle
1
830
ニーリーQAのこれまでとこれから
nealle
2
1.4k
データ分析で事業貢献するために
nealle
0
1.9k
SREチームのタスク優先度と向き合う Road to SRE NEXT@札幌
nealle
0
180
Other Decks in Programming
See All in Programming
童醫院敏捷轉型的實踐經驗
cclai999
0
210
CursorはMCPを使った方が良いぞ
taigakono
1
220
Hypervel - A Coroutine Framework for Laravel Artisans
albertcht
1
110
dbt民主化とLLMによる開発ブースト ~ AI Readyな分析サイクルを目指して ~
yoshyum
3
550
Composerが「依存解決」のためにどんな工夫をしているか #phpcon
o0h
PRO
1
250
Select API from Kotlin Coroutine
jmatsu
1
220
C++20 射影変換
faithandbrave
0
560
すべてのコンテキストを、 ユーザー価値に変える
applism118
3
1.1k
地方に住むエンジニアの残酷な現実とキャリア論
ichimichi
5
1.5k
たった 1 枚の PHP ファイルで実装する MCP サーバ / MCP Server with Vanilla PHP
okashoi
1
220
今ならAmazon ECSのサービス間通信をどう選ぶか / Selection of ECS Interservice Communication 2025
tkikuc
21
3.9k
AI時代のソフトウェア開発を考える(2025/07版) / Agentic Software Engineering Findy 2025-07 Edition
twada
PRO
53
14k
Featured
See All Featured
[RailsConf 2023] Rails as a piece of cake
palkan
55
5.6k
Navigating Team Friction
lara
187
15k
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
Rebuilding a faster, lazier Slack
samanthasiow
82
9.1k
Site-Speed That Sticks
csswizardry
10
680
Visualization
eitanlees
146
16k
Practical Orchestrator
shlominoach
188
11k
Building a Modern Day E-commerce SEO Strategy
aleyda
42
7.4k
Unsuck your backbone
ammeep
671
58k
Become a Pro
speakerdeck
PRO
28
5.4k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
35
2.4k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
357
30k
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