デプロイ自動化を進めるためのチェックリスト
いままで色々なところで言ってきたことをだらだらとまとめてみました。
計画および準備段階
- 要求される品質の定義をおこなう
- DevとOpsの双方で情報が共有されるようにする
- いつデプロイを開始するのかを明らかにする
- デプロイの際にインフラを変更する必要はあるのかを明らかにする
- デプロイを行う時間帯、行わない時間をあらかじめ決めておく(休み前を避ける)
- ブランチ戦略、マージ戦略を決める
- 継続的インテグレーションの戦略を決める
- ログの出力戦略を決める
ビルドとリリースの自動化
- 人的要素を減らす
- 繰り返し可能にする
- 自動作業と手作業を混ぜない
- ビルドを自動化する
- 誰のマシンでもビルドできるようにする
- ユニットテスト、結合テスト、UIテストなどテストを自動化する
- 本番にデプロイする際にコードを書換えなければならないといった実装を避ける
- 毎回デプロイプロセスを設計するのではなく、毎回同じ方法でデプロイする
- 毎回同じ方法が難しければ2パターンくらいのデプロイ方法に収束させる
- リリース後のテストも自動で行う
- 短期間で問題を発見するためのスモークテストを用意する
- インフラ構築やパッチ適用を自動化する
- インフラのテストも自動で行う
- セキュリティ関連の試験を自動化してプロセスに組み込む
- パフォーマンス関連の試験を自動化してプロセスに組み込む
- キーローテーションの仕掛けを自動化する
- 静的解析の仕掛けを自動化する
- 開発の段階からテスト環境やステージング環境のデプロイにも同じ仕掛けを使う
- デプロイの履歴を自動で残す
- デプロイした変更を特定可能にする
- これらが可能なアプリケーションアーキテクチャにする
- バックアップを自動化する
- 複雑な仕掛けにしない、秘伝のタレにしない
- 専用のツール、メジャーなツールを使う
- ロールバックの仕掛けを用意する
- 紙のチェックリストに頼らない
- 実行順序や依存関係の判断は機械にやらせる
- デプロイの成功・失敗も機械的に判断させる
変更量のコントロール
- 一度に変更する内容はなるべく少なくする
- とはいえ全体に影響がないとは限らないので全体を自動でテストする
- 不可逆な変更を避ける。これはDBのカラムにも言える
- デプロイに失敗したら手作業で続行しないでロールバックする
- 大規模が避けられない場合はブルーグリーンを使う
- フィーチャーフラグを使って機能のオン/オフを容易にする
- 利用者が多いAPIなどは複数バージョンを併存させる
押さえるべきKPIを明確にする
- デプロイ完了までにかかる時間を測定する
- システム監視すべき項目を設計する
- 監視の閾値を定期的に見直す
- ビジネス上のメトリクスを監視内容に含める
- ログを文字列監視する
- これらの値を簡単にリアルタイムで取り出せるようにする
デプロイ成功後のアクション
- たまにはお祝いに寿司屋に飲みにいく
- 改善すべき事項を洗い出して優先順位をつける
- 手作業が残っている箇所をつぶしていく
- ただし一気に多数のプロセス変更はしない
