機能を作るのが早ければ早いほど、価値は追加される。ユーザのフィードバックに応えてシステムを変更するのが速ければ速いほど、ユーザはたやすく満足し続ける。Timothy Fitz氏(リンク)とJoe Ludwig氏(リンク)が、継続的デプロイの実用的な実装を解説する記事を最近発表した。継続的デプロイは、リリースサイクルを数週間から数分間に減らすプロセスだ。
Timothy氏の最初の記事において(リンク)、継続的デプロイが不具合修正のコストに与える影響を調査している。エラーがシステムに持ち込まれたときからそのエラーが見つかるまでの間が長ければ長いほど、エラーの修正は難しく、費用がかかるようになる。技術者がタイプしたすぐ後に間違いを見つけた場合、その不具合のコストは基本的にゼロだ。コンパイラによって不具合を見つけた場合、開発者の時間に関してコストはおそらく数分だ。不具合が製品に入り込み、しばらくの間気が付かない場合、そのエラーを見つけて修正するコストは驚異的になる。この業界では、この劇的な例としてY2K問題が起こった。Timothy氏は、速く失敗したほうがよい、そうすれば不具合の影響とコストが最小限になるという立場を示す。
読者が投稿したコメントにおいて、継続的デプロイに関して深刻な疑念が示された。Erik A. Brandstadmoen氏が単刀直入に述べた。「現実には、あなたのアプローチは十分だとは思えません。」Y Combinator(リンク)にコメントが残された。「あぁ、違います。たぶんこれは、継続的統合の代わりに開発者が1人のときに実行可能なだけです。しかし、多数の開発者がチェックインする場合、複雑なシステムでサイトは何度もダウンするでしょう。」
懐疑的な人たちに対する返信で、Timothy氏はどのようにIMVU社(リンク)が継続してシステムをデプロイするかについて記述した(リンク) 。このプロセスでは、新しい変更を素早く構築してテストするために継続的統合から始める。重要な点の1つは、広範囲で非常に信頼性の高い自動テストだ。IMVU社では、テストスイート全体の実行時間を10分以下にするために、多数のテストマシンを使用する。全テストが通ったら、デプロイが始まる。
コードは、クラスタ内の数百のマシンにrsyncで転送されます。負荷平均、CPU使用量、PHPエラーや停止などは、基本線としてプッシュスクリプトによってサンプリングされます。symlinkは、最初の何人かの顧客のところで動くコードを投げるマシンのほんの少しの部分で動作します。1分後、プッシュスクリプトはクラスタの中でデータを再びサンプリングし、統計的に大きな後戻りがあった場合は、更新を自動的にロールバックします。そうでなければ、100%のクラスタへプッシュし、もう5分間同様にモニタリングします。そのコードは、今度は生き残って、完全にプッシュされます。
60人の従業員で、3千万人の登録ユーザと1ヵ月に百万ドル以上の収入があるIMVU社が作り出したものは、もちろん普通ではない。Michael Bolton氏(リンク)とJames Bach氏 (リンク)の調査によると(リンク)、このシステムも完璧ではない。Elisabeth Hendrickson氏(リンク)は、完璧さはシステムの目的ではなさそうだ(リンク)と指摘することによって、本文中にこのことを書いている。
Pirates of the Burning Sea(リンク)の前アーキテクトであるJoe Ludwig氏(リンク)が、顧客の非常に重いコードがある環境で継続的デプロイを行うのに本当に必要なことを調査する2つの記事を書いた。Ludwig氏は、「Pirates」の7時間半に渡るデプロイプロセスの詳細から始め(リンク)、それを1時間に減らすために必要なことの概要をまとめている。2番目の記事(リンク)では、1時間のデプロイを実現するために必要であろういくつかの重要な技術的変更について述べる。
継続的デプロイに関してあなたは何を経験しているだろうか? 継続的にデプロイできるように、あなたが取り組んでいるシステムの何を変更しなければならないだろうか?
原文はこちらです：http://www.infoq.com/news/2009/03/Continuous-Deployment