ひとつの開発環境

Transcript

1. ひとつの開発環境
 shia
 テクノロジー部門 /技術推進本部 /Platform Engineeringチーム

2. 自己紹介
 Shia - 技術推進本部 - 入社４年目 - インフラや共通基盤とかを担当
3. What Would You Do?
 本日のテーマ

4. STORES
 「STORESさえあれば、 店舗のフロント業務を全てできる」
5. STORES

6. いっぱい出しているが単に出すだけでは 十分ではない STORES

7. 全てのサービスが密に連携され一つの サービスのように使えて欲しい STORES

8. 具体例：ロイヤリティ
 お店もネットショップも、まとめてポイント導入
9. 具体例：統合管理画面

10. これら全部と付き合っていく必要がある

11. What Would You Do?
 「このような状況の中、 開発環境はどうあるべきでしょうか？」
12. 繋がる前の時代

13. 個別開発の時代

14. 事業者向け 環境のバラつき
 エンドユーザ向け & API サーバ
15. API サーバ エンドユーザ 向け reverse proxy 環境のバラつき
 事業者 向け
16. これらを管理するためのレポ API サーバ エンドユーザ 向け reverse proxy 環境のバラつき
 事業者 向け
17. All in one 環境のバラつき

18. 環境のバラつき
 …
19. 環境のバラつき
 チームを跨ぐと全く異なる環境
20. 連携の時代
 幕開け

21. 連携の時代
 事業者情報の統一
22. 連携の時代
 => 事業者 IdP
23. 連携の時代
 サービス間連携の本格化
24. 連携の時代
 サービス間連携の本格化 API Gateway
25. 連携の時代
 サービス間連携の本格化 Event Repository API Gateway
26. サービスが繋がり始まる 連携の時代

27. 連携の時代
 => 開発時に動かすべき サービスの数が増えてきた
28. お約束を決める

29. - リポジトリごとにセットアップ方法が違う - ポートが被りを避けたい - 慣れてない言語・実装は大変 大変と思うもの

30. - `make xxx`でインターフェース統一 - 開発サーバは基本コンテナ＆コンテナネットワークの中で動 かしましょう - 基盤系はあるものを使う - 面倒事は STORES-compose に投げよう お約束を決める

31. STORES を手元で開発するときに 必要な開発環境ツール群を提供するのリポジトリ STORES-composeとは？

32. 開発環境の様子
 api gateway dummy authorizer ローカル netshop リモート .local.example.com への全リクエスト イベント ブローカー Event Repository 予約 リクエスト イベント送信 認証認可 イベント受信 STORES アカウント gateway 組織管理 API イベント ブローカー 注：発表で話してないものをもろもろ省略してます
33. 開発環境の様子
 api gateway dummy authorizer ローカル netshop リモート .local.example.com への全リクエスト イベント ブローカー Event Repository 予約 STORES アカウント gateway イベント ブローカー リクエスト イベント送信 認証認可 イベント受信 注：発表で話てないものをもろもろ省略してます
34. 開発環境の様子
 api gateway dummy authorizer ローカル netshop リモート .local.example.com への全リクエスト イベント ブローカー Event Repository 予約 STORES アカウント gateway イベント ブローカー リクエスト イベント送信 認証認可 イベント受信 注：発表で話てないものをもろもろ省略してます
35. 開発したいサービスを動かすためのあらゆるもの： - HTTPS エンドポイント - リモート開発環境の接続周りの土管 - … STORES-compose が提供していたもの

36. - STORES-composeと必要なあらゆるリポジトリを git clone - STORES-compose で make dev - 必要なあらゆるリポジトリで make dev - 開発開始！ 開発の流れ

37. 現在

38. 組織の変化
 - サービス別チーム → 機能別チームへ再編 - 以前: 「自分はネットショップだけ担当」 - 現在: 「この機能のために必要な全サービスを触る」 - 一人が複数のサービスを触ることが当たり前に - 「ロイヤリティ」開発にはネットショップと BA を触らなきゃ
39. 課題が見つかる1
 揃ってるように見えて揃ってないものが多い - 「このサービス、どうやって起動するんだっけ？」 - 「環境変数はどこで設定するの？」 - 「依存性がたりてない〜」
40. これらを管理するためのレポ <- ここ API サーバ エンドユーザ 向け reverse proxy make dev どこで実行する？
 事業者 向け
41. 課題が見つかる1
 揃ってるように見えて揃ってないものが多い - 「このサービス、どうやって起動するんだっけ？」 - 「環境変数はどこで設定するの？」 - 「依存性がたりてない〜」
42. 共通基盤のリモート環境連携が足を引っ張る： 開発中に指している共通基盤側のサービスをリモート環境からローカル へ切り替えることが増えた - リモート環境とローカルでデータ不整合っぽい挙動 - リモート環境でリクエスト元がローカルかリモート環境かとい う謎分岐が生まれてた 課題が見つかる2

43. 開発サーバ in コンテナが辛い - binding.irb するのが大変 - npm install 終わらんですけーど - 壊れたときの復旧が大変さは別に変わらない? 課題が見つかる3

44. 開発そのものに集中しづらい環境になりつつあった 課題が見つかる

45. STORESは一つのプロダクトである 振り返ってみる

46. なら、開発環境も一つであるべきでは？ 振り返ってみる

47. ひとつの開発環境

48. - 揃ってるように見えて揃ってないものが多い - 共通基盤のリモート環境連携が足を引っ張る - 開発サーバ in コンテナが辛い 感じてる課題まとめ

49. 1. 管理方式の統一 - パス構造の統一 - ツール管理の統一 - 環境変数管理の統一 2. すべてローカルで動かす - ローカルで全てを完結させる - 開発サーバはホストで動かす 方針

50. mise-en-placeに全て任せる 「The front-end to your dev env」 詳細なやり方

51. 詳細なやり方
 mise-en-placeに全て任せる - 言語バージョン管理（Ruby, Node.js, Python...） - CLIツール管理（AWS CLI, ecspressoなど） - 足りんものに関しては brew \w Brewfile でがんばる - 環境変数管理 - タスク管理（makeの代替）
52. mise-en-placeに全て任せる メリット： - 開発環境の設定や使い方が集約でできる - 判断コストが下げられる 詳細なやり方

53. リポジトリパスを統一する
 
 - “$GHQ_ROOT/github.com/[org]/[repository]”
 詳細なやり方

54. リポジトリパスを統一する メリット： - 自動化の幅が広がる - e.g.グローバルコマンドで便利な操作が可能に - 全リポジトリ一括pull - 全開発サーバーを一括起動 詳細なやり方

55. リポジトリパスを統一する 気づき： - Googleは1リポジトリでpartial checkoutらしい - パスを強制するのは、実質それに似た試みではないか？ - → 実質、巨大なモノレポなのでは？ 詳細なやり方

56. 手元で全て動かす（リモート開発環境に繋げない） 支給 MBPを使い倒す！ 詳細なやり方

57. 手元で全て動かす（リモート開発環境に繋げない） メリット： - ローカルで完結するのでいろいろデバッグしやすい - データ整合性が壊れにくくなる（はず 詳細なやり方

58. 開発サーバはコンテナではなくホストで メリット： - パフォーマンス最高 - トラブルシューティングが楽 詳細なやり方

59. DB / キャッシュなどは STORES-compose で担保 - 同じDBエンジンを使う場合、同じバージョンなら共有する - 例：MySQL 8を3リポジトリで使う場合 - → 1つのMySQLインスタンスで、データベースだけ分け る - Localstack も一つ起動すれば十分 詳細なやり方

60. DB / キャッシュなどは STORES-compose で担保 メリット： - リソース節約 - 開発サーバー再起動時にこれらが邪魔しない - アプリはアプリだけに関心を持てば良い 詳細なやり方

61. 開発ビルドイメージ（devbuild）を提供（予定） ソースコードを修正しないサービスは、ビルド済みイメージをpull して動かすだけ。 詳細なやり方

62. 決済 ひとつの開発環境
 api gateway dummy authorizer ローカル Event Repository 予約 正常リクエスト イベント送信 イベント受信 STORES アカウント gateway STORES サービス 認証認可 ネット ショップ … MO 統合管理 注：発表で話てないものをもろもろ省略してます システム間通信
63. - STORES-composeをclone - `mise run up` → ミドルウェア起動 - `mise run all:up` → 全サービスをバックグラウンドで起動 - 開発したいサービスは `mise run dev` すると開発サーバに 切り替わる 開発の流れ

64. そして未来へ

65. いるいろある 欲しいもの

66. リモート検証環境(~= PR staging) 欲しいもの

67. リモート検証環境(~= PR staging) 複数リポジトリ環境だと実現が辛い 欲しいもの

68. 今目指してる環境なら - 一発で全てが起動する - 単一サーバで完結できる - インターフェースが統一されている -> 環境セットアップは自動化できる 振り返ってみる

69. 利用の流れ - どっかで環境をリクエストする - 勝手にサーバが起動する - ドメインが振られる - 起動後 git clone STORES-compose & mise run up & mise run all:up - 準備できたら url を伝える あとはよしなにブランチなどを切り替えながら使うだけ リモート検証環境

70. えーあいーってやつで もっと生産性をあげたい 時は 2025年、大AI時代

71. 複数リポジトリってあまり AI 向きではない - セットアップ方法が色々あると AI は混乱する - そもそも適切な指示がないと複数のリポジトリを跨って仕事 することができない - 手元で AI 環境用意するのがめんどくさい 注：2025/11の最新 LLM 基準です 時は 2025年、大AI時代

72. 複数リポジトリってあまり AI 向きではない - セットアップ方法が色々あると AI は混乱する - 統一した - そもそも適切な指示がないと複数のリポジトリを跨って仕事 することができない - 手元で AI 環境用意するのがめんどくさい 時は 2025年、大AI時代

73. 複数リポジトリってあまり AI 向きではない - セットアップ方法が色々あると AI は混乱する - 統一した - そもそも適切な指示がないと複数のリポジトリを跨って仕事 することができない - 頑張る - 手元で AI 環境用意するのがめんどくさい 時は 2025年、大AI時代

74. 複数リポジトリってあまり AI 向きではない - セットアップ方法が色々あると AI は混乱する - 統一した - そもそも適切な指示がないと複数のリポジトリを跨って仕事 することができない - 頑張る - 手元で AI 環境用意するのがめんどくさい - 手元じゃなければ？ 時は 2025年、大AI時代

75. エージェント on リモート検証環境 リモート検証環境 feat. Agent

76. メリット： - AI開発がスケールする - 開発者の検証が楽 リモート検証環境 feat. Agent

77. 流れ： 1. 開発者「この機能作って」 2. AI「わかりました」 3. 作業環境を起動 4. AI が実装 → テスト → PR作成 5. 開発者が動作確認 6. 問題なければマージ 7. デプロイ リモート検証環境 feat. Agent

78. What would you do?

79. What Would You Do?
 「このような状況の中、 開発環境はどうあるべきでしょうか？」
80. STORES の答え
 私たちは 「ひとつの開発環境」を作りました
81. - ひとつだけ - 手元で全て動く - 統一された管理方法 - 誰でも動かせる STORES の答え

82. STORES の答え
 これが正解かはわからない
83. STORES の答え
 これが正解かはわからない けど方向性は正しいと信じてる
84. いろんな開発環境があり、 それらを経験してきたあなたなら 違う答えを持ってるかも あなたなら、どうしますか？

85. ひとつの開発環境
 
 
 shia

91. タイトル