SRE、開発、QAが協業して挑んだリリースプロセス改革 by 宮後 啓介

■ 発表カテゴリ
・Case Studies: 実際の導入事例や失敗談

■ 発表概要（400字程度）
株式会社ニーリーは、月極駐車場のオンライン契約サービス「Park Direct」を提供するスタートアップ企業です。約2年前まで、Park Directの本番リリースは2週間に1度の頻度で行われ、必ずサービスのダウンタイムを伴っていました。また、変更による障害率も高い状態でした。
しかし、SRE、開発、QAのチームが協業して改善に取り組んだことで、現在では毎日複数回のリリースが可能になり、また、変更障害率も大幅に下げることに成功しました。
このセッションではこうした改善をおこなうために実施したプラクティスとその歩みついて紹介します。

■ 発表の詳細（1000字程度）
本セッションでは以下のアジェンダでの発表を想定しています

・Park Directが当時抱えていた課題
・実施したプラクティスの紹介
　・ブランチ戦略
　・Feature環境（プルリクエスト単位の専用環境）の導入
　・DBマイグレーションのリハーサル
　・開発DB複製の自動化
　・リリーストグル管理ツールの構築
　・パラレルテストの導入
・プラクティスによって得られた効果
・今後の取り組み

概要に記載のとおり、Park Directでは当時、リリース頻度と変更障害率について大きな課題を抱えていました。

SRE、開発、QAのチームが協業することで、どのように品質を高めながら高頻度のリリースができるようになったかの歩みをプラクティスとともに紹介します。

▼ 改善効果
・リリース頻度：2週間に1回　→　毎日（複数回も可能）
・変更障害率：Low　→　Elite

▼ 取り組んだ主なプラクティスの概要
・ブランチ戦略
　Park Directではfeature、dev、stg、prodの4つの環境を運用しています。これらの環境をどのようなブランチ戦略で実現しているのかを紹介します。

・Feature環境（Pull Reqeust単位の専用環境）の導入
　開発者がPull Reqeustの単位で専用の検証環境を作成できる仕組みを構築することで、開発生産性の向上に寄与しています。Feature環境をどのような仕組みで実現しているのかを紹介します。

・DBマイグレーションのリハーサル
　以前まではDBのマイグレーションを伴うリリースをおこなう場合、サービスを停止したうえで実施していました。マイグレーションを事前にリハーサルできる仕組みを構築することで、サービス影響を把握できるようになったのでその仕組みを紹介します。

・開発DB複製の自動化
Feature環境の導入に伴い各環境毎に開発用DBが必要となるケースが増加しました。Pull Reqeustにラベルを付与することで開発用DBを複製できる仕組みを構築したのでどのように実現したのかを紹介します。

・リリーストグル管理ツールの構築
機能のリリースを柔軟に制御するためにリリーストグルを活用してきました。しかし、トグルの数が増加するにつれ、その管理にかかる運用負荷が大きな課題となっていました。独自にリリーストグルを管理する仕組みを構築することで解決したのでその内容を紹介します。

・パラレルテストの導入
　以前まではQAによるテストはdev環境にデプロイ後に実施していたため、QAリードタイムが長く発生していました。Feature環境と合わせて、パラレルテストを開発プロセスに導入することで、QAテストのシフトレフトを実現し、QAリードタイムの短縮が行えたのでその取り組みを紹介します。

■ 対象聴衆とその人たちが得られるもの
・リリース頻度や品質に課題を持っている方
　・実際に実践し高い成果を得られたプラクティスを紹介するため、課題解決のヒントにしていただけると考えています。
・開発生産性を向上させたい方
　・Feautre環境の仕組みは機能開発以外にも汎用性が高く利用できる仕組みのため、聞かれた方の課題解決の選択肢になると考えています。

■ なぜこのトピックについて話したいのか（モチベーション）
リリース頻度や品質の向上は多くのサービスがかえる課題かと思います。ニーリーで実践したプラクティスを紹介することで、同じ課題を抱えるサービスの一助になればと考えています。