SRE、開発、QAが協業して挑んだリリースプロセス改革@SRE Kaigi 2025

by Nealle

Slide 1

Slide 1 text

2025/01/26 SRE Kaigi 2025 株式会社ニーリー宮後啓介 @miya10kei NEALLE SRE、開発、QAが協業して挑んだリリースプロセス改革 1

Slide 2

Slide 2 text

2023年にニーリーにジョイン SREとしてサービスの信頼性やアジリティ向上の施策を実施。最近はSRE業務のかたわら生成AIを用いた業務改善をしています。以前は、SIerで業務システムのスクラッチ開発、Web系企業でメールサービスやフリマサービスなど複数のサービス開発やSRE業務を担当。 2 自己紹介 @miya10kei 株式会社ニーリープラットフォーム開発G SREチームリーダー Keisuke Miyaushiro 宮後啓介

Slide 3

Slide 3 text

3 プロダクト紹介

Slide 4

Slide 4 text

複数のチームユニット 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名 ※ 業務委託/兼務を含む

Slide 5

Slide 5 text

目次 1｜抱えていた課題 2｜取り組み 3｜現在の課題と今後の取り組み 4｜まとめ 5

Slide 6

Slide 6 text

目次 1｜抱えていた課題 2｜取り組み 3｜現在の課題と今後の取り組み 4｜まとめ 6

Slide 7

Slide 7 text

7 1｜抱えていた課題デプロイ頻度の低さ変更障害率の高さ

Slide 8

Slide 8 text

8 1｜抱えていた課題 ~ デプロイ頻度 ~ 月に2〜5回ほどの頻度でしかデプロイできていない状態🥲

Slide 9

Slide 9 text

9 1｜抱えていた課題 ~ 変更障害率 ~ デプロイすると40%は障害が発生していた状態🥲

Slide 10

Slide 10 text

10 プロダクトをグロースさせていく上で高頻度に安定したリリースをしていくことは重要！ 1｜抱えていた課題

Slide 11

Slide 11 text

開発から運用まで含めたリリースプロセスの改革に着手！ 11 1｜抱えていた課題

Slide 12

Slide 12 text

目次 1｜抱えていた課題 2｜取り組み 3｜現在の課題と今後の取り組み 4｜まとめ 12

Slide 13

Slide 13 text

13 2｜取り組み開発テストリリース運用 Feature環境の導入開発DB複製の自動化テストでの本番データ利用ゼロダウンタイムリリースの実現 DBマイグレーションのリハーサルリリーストグルの運用改善パラレルテストの導入

Slide 14

Slide 14 text

14 2｜取り組み〜ゼロダウンタイムリリースの実現〜開発テストリリース運用 Feature環境の導入開発DB複製の自動化テストでの本番データ利用ゼロダウンタイムリリースの実現 DBマイグレーションのリハーサルリリーストグルの運用改善パラレルテストの導入

Slide 15

Slide 15 text

■ 課題 ● 全てのリリースがダウンタイムを伴うものになっていた ○ 頻度高くリリースができない ○ 深夜作業となり負担が大きい ■ 取り組み ● ゼロダウンタイムでのリリースを実現するために次の取り組みを実施し、ダウンタイムリリースとゼロダウンタイムリリースを選択できるようにした ○ ゼロダウンタイムでリリースすための条件を整理 ○ ゼロダウンタイムリリースの仕組みの構築 15 2｜取り組み〜ゼロダウンタイムリリースの実現〜

Slide 16

Slide 16 text

■ ゼロダウンタイムでリリースするための条件を整理 ● アプリケーション間の後方互換性が担保できていること ● DBマイグレーションが伴わないこと ○ ※ DBマイグレーションのリハーサルをおこなうことで一部緩和 16 2｜取り組み〜ゼロダウンタイムリリースの実現〜

Slide 17

Slide 17 text

■ ゼロダウンタイムリリースの仕組みの構築 ▼ 既存のダウンタイムリリース　developブランチに変更を溜め込み、リリースタイミングでstaging/masterブランチに反映 17 2｜取り組み〜ゼロダウンタイムリリースの実現〜

Slide 18

Slide 18 text

■ ゼロダウンタイムリリースの仕組みの構築 ▼ ゼロダウンタイムリリース　stagingブランチに変更を溜め込むことでダウンタイムリリースと開発ラインを分離 18 2｜取り組み〜ゼロダウンタイムリリースの実現〜

Slide 19

Slide 19 text

19 2｜取り組み〜 DBマイグレーションのリハーサル〜開発テストリリース運用 Feature環境の導入開発DB複製の自動化テストでの本番データ利用ゼロダウンタイムリリースの実現 DBマイグレーションのリハーサルリリーストグルの運用改善パラレルテストの導入

Slide 20

Slide 20 text

■ 課題 ● DBマイグレーションが必要なリリースが全てダウンタイムリリースとなっていた ○ テーブルやレコードロックによるアプリケーションへの影響を気にしていた ■ 取り組み ● 事前に本番データを用いてDBマイグレーションを実行する仕組みを構築し、ロック時間の短いマイグレーションはゼロダウンタイムでのリリースを許容するようにした 20 2｜取り組み〜 DBマイグレーションのリハーサル〜

Slide 21

Slide 21 text

GitHub ActionsのWFから本番データに対してDBマイグレーションを実行できる仕組みを構築 21 2｜取り組み〜 DBマイグレーションのリハーサル〜

Slide 22

Slide 22 text

テーブル毎のロック時間をSlackに通知し、ゼロダウンタイムでのリリースが可能かを判断 22 2｜取り組み〜 DBマイグレーションのリハーサル〜

Slide 23

Slide 23 text

23 2｜取り組み〜 Feature環境の導入〜開発テストリリース運用 Feature環境の導入開発DB複製の自動化テストでの本番データ利用ゼロダウンタイムリリースの実現 DBマイグレーションのリハーサルリリーストグルの運用改善パラレルテストの導入

Slide 24

Slide 24 text

■ 課題 ● 開発環境へのマージ前に開発中のアプリケーションを複数人で同時に触ることができない ● クラウド環境でしか確認できない事象の検証に手間がかかる ■ 取り組み ● Feature環境（＝Pull Requestの単位で作成可能な専用環境）を作成する仕組みを構築し、案件単位で並行開発しやすい環境を整備 24 2｜取り組み〜 Feature環境の導入〜

Slide 25

Slide 25 text

25 2｜取り組み〜 Feature環境の導入〜 Pull Requestへのラベル付与をトリガーに専用のFeature環境を構築 ● 21時に自動削除することでコストを削減

Slide 26

Slide 26 text

Feature環境についての詳細はテックブログに載っているので是非ご覧ください！ 26 2｜取り組み〜 Feature環境の導入〜 https://nealle-dev.hatenablog.com/entry/2024/12/20/01 https://nealle-dev.hatenablog.com/entry/2024/04/01/120409

Slide 27

Slide 27 text

27 GitHub ActionsをトリガーにSlackで操作者に通知したい場合、SlackのマイキーワードにGitHubのユーザ名を登録することで簡単に通知することができます！ ※ SlackのGitHubアプリでは多数の通知が届いてしまいノイズになってました💦 Tips｜GitHub ActionsからSlack通知をするとき

Slide 28

Slide 28 text

28 2｜取り組み〜開発DB複製の自動化〜開発テストリリース運用 Feature環境の導入開発DB複製の自動化テストでの本番データ利用ゼロダウンタイムリリースの実現 DBマイグレーションのリハーサルリリーストグルの運用改善パラレルテストの導入

Slide 29

Slide 29 text

■ 課題 ● Feature環境はDBを開発環境と共有しており、スキーマやデータの更新が全体に影響していた ● 手動で開発環境のDBを複製していたが、設定や削除漏れなどが発生していた ○ なにより手間がかかっていた、、、 ■ 取り組み ● 開発DBの複製を自動化し、Feature環境と同様にPull Request単位で専用のDBを利用可能にした 29 2｜取り組み〜開発DB複製の自動化〜

Slide 30

Slide 30 text

30 2｜取り組み〜開発DB複製の自動化〜 Pull Requestへのラベル付与をトリガーに開発環境のDBを複製する ● 21時に自動停止、9時に自動起動することでコスト削減 ● Pull Requestのマージとクローズタイミングで自動削除し消し忘れ防止

Slide 31

Slide 31 text

31 2｜取り組み開発テストリリース運用 Feature環境の導入開発DB複製の自動化テストでの本番データ利用ゼロダウンタイムリリースの実現 DBマイグレーションのリハーサルリリーストグルの運用改善パラレルテストの導入

Slide 32

Slide 32 text

■ 課題 ● 複雑な機能のテストデータの準備に時間がかかる ○ 抜け漏れなども発生し、リリース後に不具合が発覚してしまう ○ 本番データをそのままテストに利用するとデータ漏えいのリスクがある ■ 取り組み ● テストに本番データを安全に利用できるように次の仕組みを構築 ○ データの自動マスキング ○ 外部との通信を遮断 ※ マスキングと通信遮断の2段階の防止策を設けることでデータ漏洩のリスク低減 32 2｜取り組み - テストでの本番データ利用-

Slide 33

Slide 33 text

■ データの自動マスキング Pull Requestへのラベル付与をトリガーに本番DBを複製し、自動でマスキング実施 33 2｜取り組み - テストでの本番データ利用-

Slide 34

Slide 34 text

■ 外部との通信を遮断 Network Firewallを用いて外部通信を制限することで、意図しないデータ転送を抑制 ● Feature環境と同様にPRに特定ラベルを付与することで自動で構築される 34 2｜取り組み - テストでの本番データ利用-

Slide 35

Slide 35 text

35 2｜取り組み〜パラレルテストの導入〜開発テストリリース運用 Feature環境の導入開発DB複製の自動化テストでの本番データ利用ゼロダウンタイムリリースの実現 DBマイグレーションのリハーサルリリーストグルの運用改善パラレルテストの導入

Slide 36

Slide 36 text

■ 課題 ● 開発者によるスクリプトテストとQAによる探索的テストをシリアルにおこなっていたことでリリースまでのサイクルタイム増加の一つの要因となっていた ■ 取り組み ● Feature環境を利用し、パラレルテスト(＝開発者によるスクリプトテストとQAによる探索的テストの並列実施）をおこなうプロセスに変更 ○ テストがパラレルになることでサイクルタイムを短縮できる ○ Pull Requestの段階でQAからバグのフィードバックを得られる ※ パラレルテストは弊社の造語です 36 2｜取り組み〜パラレルテストの導入〜

Slide 37

Slide 37 text

37 2｜取り組み〜パラレルテストの導入〜

Slide 38

Slide 38 text

38 2｜取り組み ~ リリーストグルの運用改善 ~ 開発テストリリース運用 Feature環境の導入開発DB複製の自動化テストでの本番データ利用ゼロダウンタイムリリースの実現 DBマイグレーションのリハーサルリリーストグルの運用改善パラレルテストの導入

Slide 39

Slide 39 text

■ リリーストグルフィーチャーフラグの一種。コードのデプロイと機能リリースをフラグのOFF/ONで分離することでブランチワークの複雑化の回避とリードタイムの短縮を図る。 ■ 課題 ● 各環境（開発、ステージング、本番）のトグルの設定値を横断的に確認できない ● 不要になったトグルの削除ができておらず、コードが複雑化してしまっている ● ローカル環境への各環境のトグル状態の取り込みが大変、、、 ■ 取り組み ● 横断的にトグルの状態を確認できるダッシュボードの整備 ● 不要になったトグルを通知する仕組みを構築 ● 特定環境のトグル状態を取り込むスクリプトを作成 39 2｜取り組み ~ リリーストグルの運用改善 ~

Slide 40

Slide 40 text

■ 横断的にトグルの状態を確認できるダッシュボードの整備 40 2｜取り組み ~ リリーストグルの運用改善 ~

Slide 41

Slide 41 text

■ 横断的にトグルの状態を確認できるダッシュボードの整備 41 2｜取り組み ~ リリーストグルの運用改善 ~

Slide 42

Slide 42 text

■ 不要になったトグルを通知する仕組みを構築一定期間更新のないトグルの数が一定数を超えた場合に、開発者にSlack通知することで削除忘れを防止 42 2｜取り組み ~ リリーストグルの運用改善 ~

Slide 43

Slide 43 text

■ 特定環境のトグル状態を取り込むスクリプトを作成 43 2｜取り組み ~ リリーストグルの運用改善 ~

Slide 44

Slide 44 text

44 2｜取り組み開発テストリリース運用 Feature環境の導入開発DB複製の自動化テストでの本番データ利用ゼロダウンタイムリリースの実現 DBマイグレーションのリハーサルリリーストグルの運用改善パラレルテストの導入

Slide 45

Slide 45 text

毎日複数回リリースできる状態まで大きく改善！ 45 2｜取り組み - デプロイ頻度改善の効果 -

Slide 46

Slide 46 text

10%程度まで低減することができ大きく改善！ 46 2｜取り組み - 変更障害率改善の効果 -

Slide 47

Slide 47 text

目次 1｜抱えていた課題 2｜取り組み 3｜現在の課題と今後の取り組み 4｜まとめ 47

Slide 48

Slide 48 text

48 3｜現在の課題と今後の取り組み ■ 課題 1. リリースの相乗り待ちが発生してしまっている ○ stagingブランチに変更を溜めてからリリースしているため、複数チームの変更がリリース可能な状態になるのを待つ必要がある 2. 開発プロセスにおける開発者の負担が大きい ○ 案件Doc作成、実装、テスト設計・実施、リリースなど多くの作業を担っている

Slide 49

Slide 49 text

49 3｜現在の課題と今後の取り組み ■ 今後の取り組み 1. リリースの相乗り待ちが発生してしまっている →　トランクベース開発に移行し、直接maserブランチへマージ／リリースしていくことで相乗り待ちをなくしていく 2. 開発プロセスにおいて開発者の負担が大きい →　テスト設計、スクリプトテストの実施をQAが担うことで開発者の負担の低減を図る

Slide 50

Slide 50 text

目次 1｜抱えていた課題 2｜取り組み 3｜現在の課題と今後の取り組み 4｜まとめ 50

Slide 51

Slide 51 text

● 高頻度で安定したリリースを実現するまでの課題と取り組みを紹介 ● リリースに至るまでのプロセス全体を見て、課題を解決していくことが大きな効果につながった ● そのためにも、SRE、開発、QAといったプロセスに関わる複数のチームが協業して取り組むことが重要 51 4｜まとめ