5分で分かるデプロイ自動化への道

12月20日に第1回ワンクリックデプロイ勉強会で、デプロイの自動化について好き勝手に喋ったりデモしたりする予定なのですが、当日話す内容の概略について以下に載せておきます。以下にあげることをやっておけばデプロイ自動化、ワンクリックデプロイはそんなに遠くないところにあると思います。

デプロイ自動化への道

ソースコードのバージョン管理
- いわずもがな。全ての起点はここにある
- コードの共同所有の原則への理解
- このソースコードは本番環境または開発環境などで同じように動作しなければならない
- テストを書く習慣、コミット前に他のテストも含めて通してからコミットする習慣
設定ファイルのバージョン管理
- 環境によって異なる設定値（接続先データベース情報など）が書かれた設定ファイルもバージョン管理する
- 開発環境用、ステージング環境用、本番環境用などに分けて定義し、容易に切り替え可能にする
- 本番環境に配置する際に、アプリケーションの各所を書き換えなければ動作しないという状況は避ける
データベーススキーマとデータのバージョン管理（マイグレーションの導入）
- データベースのスキーマの状態とリリースの状態を関連付ける
- sql文のスクリプトファイルは管理が面倒だし自動実行に向かない（ロールバックやデータ移行の考慮もしづらい）
- さらには複数のsqlを書いたファイルがあったとして、データベースの状態は実行順序に依存する可能性があるし、スクリプト間で実行順序の制御ができない
- なのでマイグレーション用のツールを使う (Railsならmigration、PHPならDoctrineとかとか)
動作させるサーバのミドルウェアのインストール自動化や設定自動化
- いつでもクリーンな動作環境を作れるようにする
- この自動化によって後はアプリケーションをデプロイすればすぐ動作する状態にする
- 本番環境とバージョンをあわせる
- ミドルウェアのバージョンをあげる場合も、この自動化機構を使って行う
- 今はVMwareやVirtualBoxなど仮想化のツールがあるので、ミドルウェアのインストールのテストも容易だ
テスト自動化
- テストが通っていないものをメクラでデプロイすることはできない
- デプロイするたびに全体を人手でテストするのは無理
- スクラムであれば、出荷可能な製品の増分をスプリント最後に用意するときに、自動化されたテストがないと段々出荷可能にしにくくなる。スプリントにいつも残タスクが残るチームがあるが、たいていの場合テストの箇所に原因がある
- テストの種類と戦略
  - ユニットテスト　・・・カバレージ80〜90%以上。コミット毎に自動実行
  - 結合テスト・受け入れテスト　・・・夜間実行など。出荷前にも実施。本番環境にデプロイした際にたぶん動作していることを確認するスモークテストも準備しておく。
CIサーバの構築
- プロジェクト初期の段階でコードがなくても構築する
- コードのメトリクスや静的解析は初期から継続的に実施する方が効果がある
- 常にグリーン(Jenkinsなら青)の状態を保ち、エラーがある状態に慣れない
- 常にグリーンに保つにはアトミックな単位での作業、マイグレーションとの連携、チームのコミットに対する態度が欠かせない
デプロイスクリプトの作成
- プロジェクト開始時点で、ゼロデプロイできるようにする
- 常にデプロイスクリプトを通じてデプロイし、デプロイ先を直接修正しない
- 開発環境や本番環境問わず、同じ方法でデプロイする
- デプロイが失敗した場合にロールバックできるようにする
- デプロイが途中で失敗した場合、その先を手動でやらない