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
メンテが命: PHPフレームワークのコンテナ化とアップグレード戦略
Search
shunta ichikawa
February 21, 2025
Programming
0
420
メンテが命: PHPフレームワークのコンテナ化とアップグレード戦略
shunta ichikawa
February 21, 2025
Tweet
Share
More Decks by shunta ichikawa
See All by shunta ichikawa
20240711_RAGを用いたシンプルな 社内情報検索システムを導入した話とつらみ
shunta27
2
5.2k
Other Decks in Programming
See All in Programming
Webの外へ飛び出せ NativePHPが切り拓くPHPの未来
takuyakatsusa
2
550
Azure AI Foundryではじめてのマルチエージェントワークフロー
seosoft
0
170
WebViewの現在地 - SwiftUI時代のWebKit - / The Current State Of WebView
marcy731
0
120
生成AI時代のコンポーネントライブラリの作り方
touyou
1
210
Deep Dive into ~/.claude/projects
hiragram
14
2.5k
Startups on Rails in Past, Present and Future–Irina Nazarova, RailsConf 2025
irinanazarova
0
100
PicoRuby on Rails
makicamel
2
130
第9回 情シス転職ミートアップ 株式会社IVRy(アイブリー)の紹介
ivry_presentationmaterials
1
320
明示と暗黙 ー PHPとGoの インターフェイスの違いを知る
shimabox
2
510
20250704_教育事業におけるアジャイルなデータ基盤構築
hanon52_
5
790
設計やレビューに悩んでいるPHPerに贈る、クリーンなオブジェクト設計の指針たち
panda_program
6
2.1k
今ならAmazon ECSのサービス間通信をどう選ぶか / Selection of ECS Interservice Communication 2025
tkikuc
21
4k
Featured
See All Featured
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
10
950
Agile that works and the tools we love
rasmusluckow
329
21k
Raft: Consensus for Rubyists
vanstee
140
7k
Side Projects
sachag
455
42k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
138
34k
Become a Pro
speakerdeck
PRO
29
5.4k
The Cost Of JavaScript in 2023
addyosmani
51
8.5k
Building Adaptive Systems
keathley
43
2.7k
Embracing the Ebb and Flow
colly
86
4.7k
The Straight Up "How To Draw Better" Workshop
denniskardys
234
140k
jQuery: Nuts, Bolts and Bling
dougneiner
63
7.8k
The Invisible Side of Design
smashingmag
301
51k
Transcript
メンテが命: PHPフレームワークのコンテナ化とアッ プグレード戦略 PHPカンファレンス名古屋2025
自己紹介 市川 俊太 いちかわ しゅんた (38歳) 株式会社助太刀 開発部 開発部長 •
猫が好き • 趣味はサッカー観戦 • Ruby/PHPなどのLL言語が好き • 三重県四日市出身、愛知県内の大学通ってました!
会社紹介 事業者間マッチング 協力会社探し 正社員採用 工事会社の人手不足を マッチングと 正社員採用で解決
アジェンダ 1. サービスは生き物だ 2. レガシー環境が生まれる理由 3. 解決するための3つのアプローチ
アジェンダ 1. サービスは生き物だ 2. レガシー環境が生まれる理由 3. 解決するための3つのアプローチ
サービスは生き物だ サービスは生き物(or 水物?)。放置すると...? ?
サービスは生き物だ 腐ります。(鮮度が落ちます )
ソフトウェアに例えると • PHP / アプリケーション(Laravelなど)/ データベース(MySQLなど)のバージョンが古い(EOL) • メンテされてないコード • AWSのインスタンスのスペックが古い
• インデックス管理がされていない 放置すると...?
ソフトウェアに例えると • PHP / アプリケーション(Laravelなど)/ データベース(MySQLなど)のバージョンが古い(EOL) => セキュリティリスク • メンテされてないコード
=> デプロイ(リリース)するのが怖い • AWSのインスタンスのスペックが古い => パフォーマンス低下 • インデックス管理がされていない => クエリが遅くなる
これが続くと... • リリースするのが怖くなる • (開発しにくいから)エンジニアが離職 • ユーザ体験が悪化(バグ・遅い・クラッシュなど)
アジェンダ 1. 自己紹介 2. サービスは生き物だ 3. レガシー環境が生まれる理由 4. 解決するための3つのアプローチ
レガシー環境が生まれる理由 • 動いているから放置 • 新機能開発が優先され、アップデートなどは後回し
動いているから放置 「壊れるリスクを負ってまで触りたくない」 「アップデートしなくても動いてるから大丈夫でしょ?」
動いているから放置 「壊れるリスクを負ってまで触りたくない」 「アップデートしなくても動いてるから大丈夫でしょ?」 動いてるから「このままで問題ない」という心理が働き放置
動いているから放置 「壊れるリスクを負ってまで触りたくない」 「アップデートしなくても動いてるから大丈夫でしょ?」 動いてるから「このままで問題ない」という心理が働き放置 突如、AWSからメールがやってきます...
動いているから放置 放置すると最悪データベースが止まります...
レガシー環境が生まれる理由 • 動いているから放置 • 新機能開発が優先され、アップデートなどは後回し
新機能開発が優先され、アップデートなどは後回し 「✅新機能開発」 「✅新機能開発」 「🚀 リリース」 「🚀 リリース」 「🛑アップデート後回し(忙しいから後で …)」
新機能開発が優先され、アップデートなどは後回し 「✅新機能開発」 「✅新機能開発」 「🚀 リリース」 「🚀 リリース」 「🛑アップデート後回し(忙しいから後で …)」 「AWSからメールも来てるし、アップグレードするか
…」
新機能開発が優先され、アップデートなどは後回し 「✅新機能開発」 「✅新機能開発」 「🚀 リリース」 「🚀 リリース」 「🛑アップデート後回し(忙しいから後で …)」 「❌いざ変更変更しようにも、影響範囲がわからない…」
「😨当時を知る人間もいない...」 変更が怖くなり、そのまま放置
アジェンダ 1. 自己紹介 2. サービスは生き物だ 3. レガシー環境が生まれる理由 4. 解決するための3つのアプローチ
解決するための3つのアプローチ 1. テストの導入(ユニット、機能テストなど) 2. コンテナ化 3. 継続的なアップグレード
1. テストの導入(ユニット、機能テストなど) テストが存在しないと... • コードを変更したら、別の場所でエラーが発生 • リファクタリング、バージョンアップの度に確認が大変 • 変更の度に手動テストを頑張ることになる
1. テストの導入(ユニット、機能テストなど) どうやって導入していくのか • テストがない環境で、いきなり理想的なテストを導入するのは難しい • 簡単なところから始める
1. テストの導入(ユニット、機能テストなど) どうやって導入していくのか • テストがない環境で、いきなり理想的なテストを導入するのは難しい • 簡単なところから始める 「小さくはじめる」のが大事
1. テストの導入(ユニット、機能テストなど) 例えば「ログインAPI」のレスポンスの機能テスト
1. テストの導入(ユニット、機能テストなど) 例えば「ログインAPI」のレスポンスの機能テスト • 最初は大味なテストでも良い ◦ 最初から全てのケースを網羅しよう としなくていい ◦ APIのレスポンスが期待通りかどう
かを確認するだけでいい • テストが習慣化されていることが大事 ◦ 最初は「最低限の動作確認」を意識
1. テストの導入(ユニット、機能テストなど) CI/CD に組み込んでテストを継続的に実行する • テストは書くだけでは意味がない => 継続的に実行することが重要 • CI/CDに組み込むことで
◦ コード変更時に自動テストが実行される ◦ テストの陳腐化を防ぐ
1. テストの導入(ユニット、機能テストなど) テストが存在すれば... • コードを変更したら、別の場所でエラーが発生 => 影響範囲が明確になり、エラーがすぐ検知できる • リファクタリング、バージョンアップの度に確認が大変 =>
テストがパスしていれば、既存の機能に大きな影響を与えずに変更できることが 確認できる • 変更の度に手動テストを頑張ることになる => 手動で行う必要はなく、テスト実行に関する負担を軽減
解決するための3つのアプローチ 1. テストの導入(ユニット、機能テストなど) 2. コンテナ化 3. 継続的なアップグレード
2. コンテナ化 • 環境差異によるエラー • デプロイの手間が増えることによるミス • ロールバックによるダウンタイム発生 コンテナ化しないと起こる問題
2. コンテナ化 なぜコンテナ化するのか 1. 環境の一貫性 2. スケーラビリティの向上、リソースの最適化 3. CI/CDパイプラインとの統合が容易
2. コンテナ化 • 環境差異によるエラー => コード管理されたイメージファイルを利用するだけ • デプロイの手間が増えることによるミス => GithubActionsなどのCI/CDパイプラインに統合することで
ビルド 🏭 => テスト✅ => デプロイ🚀 まで自動化(属人化なども排除) • ロールバックによるダウンタイム発生 => 過去のイメージをデプロイするだけ コンテナ化しないと起こる問題
解決するための3つのアプローチ 1. テストの導入(ユニット、機能テストなど) 2. コンテナ化 3. 継続的なアップグレード
3. 継続的なアップグレード 時間とともに通常開発とアップグレード作業の差が開いていく
3. 継続的なアップグレード 時間とともに通常開発とアップグレード作業の差が開いていく
• テスト・検証サイクルの高速化 ◦ CI/CDパイプラインにて自動実行 • ローカル環境での検証が容易 3. 継続的なアップグレード テストの導入とコンテナ化による開発・検証の効率化 通常開発と並行して、バージョンアップ作業もスムーズに実施可能
3. 継続的なアップグレード • データベースをバージョンアップ予定のコンテナイメージを利用する • PHPなども同様、バージョンアップ予定のコンテナイメージを利用する データベースやPHPのバージョンアップがしたい バージョンアップ予定のコンテナイメージを利用しテスト実行する
• PHP7.1 => PHP8.3 • Laravel5.8 => Laravel11 • 同時にMySQL5系
=> 8系 3. 継続的なアップグレード このアプローチを通して、通常の開発と並行しながら、 約3年間かけて… (無事故で)バージョンアップすることに成功🥳
サービスは生き物だ 鮮度を保つことができます
None
あなたはこの3つのアプローチなしで、バージョンアップを無 事故で行える自信がありますか?
とはいえ、やっていることは特別なことではなく...
テストとか、コンテナ化とかって
「やらなきゃならないことをやるだけさ、だからうまくいくんだ よ」 映画「アイデン&ティティ」(みうらじゅん原作)
皆様、ご清聴ありがとうございました!