デプロイの要件とは

・アプリケーションの構成要素

どんなプログラミング言語、フレームワーク、ミドルウェアを使って開発されたアプリか？

・実行環境や規模

どんなサーバ何台にデプロイするか

・許容時間

デプロイ開始から終了までにどれくらい時間をかけて良いか

・納期はいつまでか

自動化にかける時間があるのか

・予算はいくら使えるか

自動化にかける初期費用が出るのか

例えば、毎回同じプログラミング言語・フレームワーク・ミドルウェアを使って開発して、毎回同じサーバへデプロイするのであれば、話は少し簡単になる。しかし、そうではないところにデプロイの難しさがある。

手作業でいいのでは？

前述の通り、多岐にわたるデプロイの要件について、私たちは自動化または手作業で対応する。

手作業は初期費用が少ないというメリットがある一方、手順書を作成したり作業を実施するための人的コストが継続的にかかったり、繰り返し作業する中でミスが発生する可能性があるというデメリットがある。自動化したいところ。

自動化すればいいのでは？

自動化には、越えなければいけない壁がある。生産性と保守性についての壁。

生産性の壁

シェルスクリプト

新規開発する場合は、独自にデプロイの枠組みを考えるか、OSSなど既存のものを利用するかという選択肢がある。独自に作った部分は実装やテストのコストがかかるし、かといって既存のものを流用する場合には学習コストがかかります。すこしでも楽に早く実装したいところです。

保守性の壁

〜引き継ぎは？育成は？〜

独自に開発すると、引き継ぎがむずかしい場合があります。設計や実装のポイント、何か設定できて何が設定できないのか・・・。十分なドキュメントを自分で書いて残すことができればいいのですが、時間や予算の都合でスクリプトだけ実装して、ドキュメントはない、ということもあるのではないでしょうか。すこしでも楽に引き継ぎや育成をできるようにしたいところです。

自動化したい

そんなわけで、実際にわたしたちがデプロイを自動化するときには、生産性、保守性、そしてそもそものデプロイの要件のトレードオフを考えなければなりません。これは難しい判断です。仮に「今回は時間がないから手作業でカバー」や「とりあえずシェルスクリプトで自動化しよう。ドキュメントは必要になってから」といった対応になってしまったとしても、それは仕方のないことです。

しかし、理想をいえば、生産性と保守性の壁をこえてサクッと自動化したいですよね。

Capistrano 3ではじめる自動化

前述の生産性と保守性の壁をこえる一つの方法は、学習と引き継ぎのコストを下げることです。