まずは参考文献
システム運用アンチパターン
システムの開発・運用範囲が異なるエンジニア間でも、共通して会話ができる社内輪読会にはよい書籍
本章のまとめ
・ デプロイが大ごと ＝ デプロイ戦略に何か深刻な問題がある
・ 業務時間外のデプロイ = 組織を守るためとして正当化されがちなアンチパターン(対症療法でしかない）
8.1 苦労話
簡単にリリースができず、リリースとリリースの間が長期間で運用しているケース
・在庫をもっっている状態
保管、トレースのコストが発生、価値を生まない状態
遅いリリースプロセスの悪影響
リリースの詰め込み
- リリース規模が大きくなり、リリースのリスクを増大させる
大急ぎの機能
- 次のリリースタイミングまでに急いで機能を開発
重厚な変更管理プロセス
- リリースが大きくなるとリスクが増大、リスクが増大すると失敗の影響も増大。その結果承認、変更管理の層、つまりゲートキーパーが増加して、プロセスがさらに複雑に
所感
レガシーかつ、商品において、こういう状態のものを苦々しく思い出した。
それ以外にも多くの課題を抱えていたシステムだったけれど、「デプロイを簡単にするためにはどうしていけば実現できるか」
という視点から立て直しの計画を立てる方法がよかったのかもしれないと気付かされた。
一番重かったのはリリース作業だったのだけれど、インシデント、セキュリティインシデントが多く、とりあえず穴を塞ぎにいって、先の見えない戦いをしていた。
8.2 デプロイのレイヤ
データベースデプロイ
- 新しいコードのデプロイの一環としてデータベースに必要な変更を行うプロセス
アーティファクトデプロイ
- 1台のサーバに新しいコードをインストールするプロセス
フリートデプロイ
- 複数のサーバにアーティファクトをデプロイするプロセス
機能デプロイ
- アプリケーション全体で新機能を有効にするプロセス
所感
機能デプロイといわゆるコードデプロイ（アーティファクトデプロイ、フリートデプロイ）を分けるアプローチはあまりしたことがなかったが、
リリース日とデプロイを分けられるので、エンジニアとしては心配事から解放される期間が設けられるのでユースケースによっては有効かもしれない。
実装（テストも)がその分複雑になることと、あとで必要に応じて、機能スイッチを削除する必要があることとのトレードオフで判断が必要
8.3 デプロイを日常的に行う
- 8.3.1 正確な本番前環境
- 8.3.2 ステージング環境は本番環境とまったく同じにはならない
・本番前環境はアーキテクチャ/トポロジー的に本番環境と同じ環境を実現すること
- 物理サーバー台数、ファイルサーバ、ネットワーク境界
・ただ、本番環境と完全には同じにはできない
- ユーザー数（並行実行性）、想定外の操作
所感
・完全に同じにできない。でも同じにできるところを同じにしていないことは、特に昔のシステムにおいてはよくある話。
・アーキテクチャ以前にミドルウェアのバージョンが違っていたりすることもあった
8.4 頻繁に行うことで恐怖心を減らす
慣れが大事。恐怖心が軽減される。なので頻繁にデプロイすることが良いこととなる
逆に、抵抗感と恐怖心で負のフィードバックループが発生する
8.5 リスクを減らして恐怖心を減らす
自動テストから始めよう
[よくある誤解]
自動テストはすべてのバグを発見できなければ何の価値もない
[正]
テストするケースやシナリオを継続的に追加することで、継続的に価値を生み出し続けます。
リリースに関する不確実性を完全に取り除くことはできません。
しかし、その不確実性をあなたや組織が許容できる範囲まで減らすことは可能です。
デプロイ頻度を上げるには、テストの実行頻度を上げることから始めなければいけません。
8.6 デプロイプロセスの各レイヤでの失敗への対応
各レイヤでロールバックできるようにしましょう
8.6.1 機能フラグ
8.6.2 いつ機能フラグをオフにするか
・リリースする機能をオン/オフするスイッチを設置することで機能単位で戻しができる。
・機能の効果を計測し、OK/NG判断をできるようにしましょう
・OKであれば、スイッチは適宜削除リリースするようにしましょう。
8.6.3 フリートのロールバック
ブルーグリーンデプロイでいつでも切り替えできるように。
注意点
- DBスキーマがアプリケーションのバージョン間での互換性があるか
- バックグラウンド処理が同居してないか
- アプリケーションサーバがローカルディスクに状態を保存していないか
8.6.4 デプロイアーティファクトのロールバック
パッケージ管理システムは使いましょう
ロールバック時にuninstallもできるので、ブルーグリーンで違うサーバー群との環境差が広がらない
8.6.5 データストアレベルのロールバック
データベースの変更のルール
常に追加的変更を加えること！！
既存のものを変更するのは避ける
8章の所感
複雑に絡み合った問題をそのまま闇雲に解決するのでなく、
レイヤ分けして、課題を分解して、順序づけて解決していく
って当たり前だけれど、大事。