Stelligent(source)のPaul Duvall氏は最近の記事(source)で、継続的インテグレーション(source)を継続的リリース(Continuous Production)(source)に成長させるために必要なアクティビティについて書いている。継続的リリースとはまとめてリリースする代わりに、絶えずソフトウェアをリリースし続けるプラクティスのことである。
この記事では、継続的リリースでの一般的プラクティスについて触れている。これらのプラクティスは、継続的インテグレーション(ビルド、統合、テスト)の一般的なタスクから拡張したものだ。
- 継続的なデータベース統合/マイグレーション
- 開発、QA、運用テストおよび本番運用へと自動的に成果物を展開すること。
- リモートデプロイ(SmartFrog や Capistranoのようなフレームワークを利用)
これらのプラクティスは、どのようにして製品ライフサイクルに影響を与え、さらには組織をよりアジャイルにするだろうか。Chris May氏はブログにこう書いている:
（一般的に言われている）「早く、頻繁にリリースする」ことは、頻繁の度合いがどうであれ、効果が薄れることはありませんリリースが小規模で迅速であればあるほど、後戻りはより少なく、より早くユーザへ機能を提供でき、そしてより早くチームへフィードバックすることができます。基本的に、彼ら[Flickr]は機能およびバグフィックスを完了するたびにすぐリリースします。-- 彼らはリリースをまとめようなどとは考えないのです。わたしたちはまとめてしまうのですが。Tim O'Rielly氏は、2005年の記事(source)「ウェブ2.0とは何か」でコメントしている。
[「早く、頻繁にリリース」というオープンソースの格言は、「永遠のベータ」というより進歩的な概念へ変化しました。ソフトウェアはオープンな環境のもと、月ごと、週ごと、時には日ごとに新しい機能が加えられています。Gmail、Google Maps、Flickr、del.icio.us、のようなサービスから、何年もの間「ベータ」ロゴが外れなかったとしても不思議ではありません。まさにこの意見は、アジャイルにビジネスを行う上での基本的な態度であると言えるだろう。ZDNet(サイト・英語)は2005年に公表した記事(source)「なぜマイクロソフトはグーグルを破ることができないか」の中で次のように述べている。
マイクロソフトのビジネスモデルは、2～3年ごとにコンピュータ環境をアップグレードしてくれるユーザに依存します。グーグルは、毎日のように新しいものを探し出すユーザに依存します。このことは、製品のリリース形式によって、顧客ニーズの変化へ対応するやりかたが制限されてしまうということを示している。
InfoQ読者は、継続的リリースに関するどのような経験があるだろうか？継続的リリースは普通のプロジェクト・チーム(さらには属する組織)に特別のアジャイルさを与えてくれるだろうか？それとも、ここで示したような極めて裕福な組織でなければ、コストを正当化できないのだろうか？
原文はこちらです：http://www.infoq.com/news/2008/02/continuous-production