小さく段階的リリースすることで深夜メンテを回避する

PHPerKaigi 2025のLT発表のスライドです

---

「いつまでも できると思うな 夜メンテ」

深夜メンテナンス作業を経験したことはありますか？
作業には様々なメリット・デメリットがありますが、何よりも体力的に辛いですよね。

あるカラムの暗号化作業を進める中で、深夜メンテナンスが必要だという結論になりました。しかし、シニアエンジニアに相談したところ、「今回は深夜メンテができるが、できないサービスも世の中にはある。深夜メンテ不要でリリースする方法を一度考えてみては？」というアドバイスを受け、リリース方法をチームで再考しました。
その結果、リリースを3段階に分けた小さなリリースを採用することで、深夜メンテを回避することができました。さらに、小さくリリースしたことで、各リリース段階で不具合が発生した際も原因を特定しやすく、迅速に戻せる状態の確保ができました。

# お話しする内容
- 小さくリリースすることのメリット・デメリット
- 「小さくリリースできるかも？」と考えるためのヒント

開発者にとっても、ユーザーにとっても、メンテナンス時間は短いほど嬉しいものです。
このLTでは、深夜メンテに頼らずにリリースを進めるための工夫や実例を共有し、参加者にとって実践的なアイデアとなるような内容をお届けします！

Transcript

1. 小さく段階的リリースすること で深夜メンテを回避する まきまき 2025/03/23 PHPerKaigi 2025 1
2. まきまき　 　　　　　　　 @_mkmk884 愛媛→京都→小田原 NE株式会社　アプリケーションエンジニア 来月は PHPカンファレンス小田原 みなさん次はぜひ小田原へ🏯 2
3. 3 断続的に動いているサービス 止めたくないですよね？ 止めたく なーい 止められたく なーい 開発者 ユーザー
4. 4 システムを止めるための 深夜メンテナンス したくないですよね？ 眠い…… しんどい…… 開発者 \ さらに /
5. わたしたちは止めてリリースすることにした 5 過去に深夜メンテで やってるし 同じようにしよ 定期的に動いている処理に用いるデータを書き換えるとき、 動いている処理を停止して、 1リリースで一気に書き換え＆運用をする方針にしていた
6. 6 ちなみに そのリリースって本当に夜間メンテが 必要なやつなんですか？ \ ﾍﾞﾃﾗﾝ /
7. 7 うちのサービスは深夜メンテができるんですけど、 できないサービスも世の中にはあります。 そのときのことを考えて一回やらない方法を考えてみても 良さそうに思いました。 \ ﾍﾞﾃﾗﾝ / 一応 ベテランとして アドバイス しておきますね
8. 8 え…たしかに……？ しなくてもいける道があるのか…？
9. 9 \ ﾄﾞｰｼﾖ / チームで再考 \ ｺﾚﾊ ﾄﾞｳ? /
10. 10 3つに分割して段階的にリリース ↓ 深夜メンテナンスを回避
11. どうして段階的にリリースできたのか 11 1. やりたい変更を処理単位で分割できないかを考える • 変更手順を追ってみる 2. もし戻したいときの逃げ道を確保する • 修正対象を絞る • どの段階で、どうデータや処理がなっていると よいのかを洗い出す
12. どうして段階的にリリースできたのか 12 1. やりたい変更を処理単位で分割できないかを考える • 変更手順を追ってみる 2. もし戻したいときの逃げ道を確保する • 修正対象を絞る • どの段階で、どうデータや処理がなっていると よいのかを洗い出す
13. 13 第１段階 データを避難させる
14. 第１リリース 14 1. 一時利用用カラムを作成し、既存カラムの中身をコピー 既存カラム橋 一時カラム橋 14
15. 第１リリース 15 既存カラム橋 2. 一時利用用カラムを参照するようにソースを書き換える 一時カラム橋 15
16. 16 第２段階 値を加工して元の場所にいれる
17. 第２リリース 17 既存カラム橋 3. 既存カラムを一時利用用カラムをもとに加工して保存 一時カラム橋 17
18. 第２リリース 18 既存カラム橋 4. 既存カラムを参照するようにソースを書き換える 一時カラム橋 18
19. 19 第３段階 避難場所を消す
20. 第３リリース 20 既存カラム橋 5. 一時利用用カラムをDROP 20
21. どうして段階的にリリースできたのか 21 1. やりたい変更を処理単位で分割できないかを考える • 変更手順を追ってみる 2. もし戻したいときの逃げ道を確保する • 修正対象を絞る • どの段階で、どうデータや処理がなっているとよい のかを洗い出す
22. もし問題が発生した場合にリカバリができる 22 既存カラム橋 移行もできるし、戻せる 一時カラム橋 22
23. 23 無事 サービスを止めることなく 段階的リリースできました
24. 方針を考えるときに意識したこと 24 • 定期的に動いている処理を止めないこと • 途中で問題があれば、 ◦ 戻せるようにすること ◦ 方針を変えられるようにすること
25. 25 アジリティを支える品質特性 / Agility and Quality Characteristics Developers Summit 2021 Summer 和田卓人 twada
26. 小さく段階的にリリースするために意識したこと 26 チーム全員で1つのボードを 見ながら方針を話し合う → 認識合わせ • 大きな流れ • 開発手順 • その時のDBの値の状態 • タスクの分け方 • リリースの分け方 ※ 記載内容はイメージです
27. チーム全体で認識合わせをするメリット 27 • レビューでの内容理解が速くなる • チームの誰でもタスクを持てる状態になる ◦ もし問題・障害が発生したときにすぐ対応できる 確率が上がる • タスクを並行して進めることができる
28. チーム全体で認識合わせをするメリット 28 • レビューでの内容理解が速くなる • チームの誰でもタスクを持てる状態になる ◦ もし問題・障害が発生したときにすぐ対応できる 確率が上がる • タスクを並行して進めることができる
29. 小さくリリースすることのメリット 29 • 問題・障害が発生したときに問題箇所を発見しやすい ◦ 次のリリースで気をつけるところがわかる • 1つのPRの差分が少なく、読みやすい • 知識や作業の属人性を減らせる ◦ 担当者の不在、組織の変化に対応できる • タスクが捌けている感が気分がいい
30. 小さくリリースすることのメリット 30 • 問題・障害が発生したときに問題箇所を発見しやすい ◦ 次のリリースで気をつけるところがわかる • 1つのPRの差分が少なく、読みやすい • 知識や作業の属人性を減らせる ◦ 担当者の不在、組織の変化に対応できる • タスクが捌けている感が気分がいい
31. 小さくリリースすることのメリット 31 • 問題・障害が発生したときに問題箇所を発見しやすい ◦ 次のリリースで気をつけるところがわかる • 1つのPRの差分が少なく、読みやすい • 知識や作業の属人性を減らせる ◦ 担当者の不在、組織の変化に対応できる • タスクが捌けている感が気分がいい 1日で終わるくらいに しておくと 次の日に持ち越さなくて ハッピー
32. 小さくリリースすることのデメリット 32 • 全体像が見えづらくなる → ドキュメントに記載して、可視化をしておく • 依存関係の管理が複雑化する → チーム全体で認識を揃え、優先度を精査する
33. 小さくリリースすることのデメリット 33 • 全体像が見えづらくなる → ドキュメントに記載して、可視化をしておく • 依存関係の管理が複雑化する → チーム全体で認識を揃え、優先度を精査する
34. まとめ 34 • メンテナンス時間がなくリリースできる方法はないかを 考えてみることが大切 • 深夜メンテを回避する方法の1つとして 小さく段階的にリリースするという方法がある ◦ 問題が発生したときに問題箇所を発見しやすい ◦ 方針転換がしやすい
35. 35 い つ ま で も で き る と 思 う な 夜 メ ン テ