アトラシアンにおける継続的デプロイ

Jens2userpic-35-100x100.png*本ブログは ATLASSIAN blogs を翻訳したものです。本文中の日時などは投稿当時のものですのでご了承ください。 
*原文 : 2011 年 2 月 16 日、
Jens Schumacher 投稿 “Continuous Deployment at Atlassian

「早くテストしよう、頻繁にテストしよう」。この古いソフトウェア開発の原則は、テストだけではなく多くの分野に適用されます。頻繁に何かをすると、それについて上手になるということは事実です。たとえ、エキスパートになることを目的としない場合でもです。
従来のソフトウェアは、プロセスの各段階が順番に次の段階へと続く、ウォーターフォールモデルで開発されてきました。このプロセスの終盤には、デプロイやリリースのいくつかのタイプが待ち受けています。本当に苦しいデプロイやリリースです。なぜでしょうか?リリースが、年に1回程度しか行われないからです。
アジャイル開発手法を採用することにより、チームは反復的で漸進的な開発プラクティスを行い、リリースサイクルを短縮し始めました。デプロイは短縮され、2〜6週間ごとにソフトウェアの新しいバージョンをデプロイするようになりました。より多くデプロイすると、より上手になる、ということを忘れないでください。たとえ2週間ごとにそれを行う場合でも、多くの手動ステップがあり、数時間かかるデプロイのプロセスでもおそらく満足するでしょう。しかし1日に20回デプロイしなければならないとしたらどうでしょうか?継続的デプロイを説明しましょう。本日発表した Bamboo 3.0 の折り紙つきの機能です。

継続的デプロイ

継続的デプロイは、必ずしも全てのコミットが本番環境にリリースされることを意味するわけではありません。あなたが開発している業界や製品により、しばしば不可能なこともあるでしょう。また、製品の継続的なアップデートは、関係者や変更の種類によっては、カスタマーエクスペリエンスを悪くしてしまうかもしれないということを、プロダクトマネージャーとして主張しておきます。しかし、継続的デプロイからチームが受ける恩恵は多くのものがあります。
アトラシアンにおいては Confluence 4 の新しいエディターに取り組んできました。全く新しい XHTML のバックエンドをもった、完全な WYSIWYG のエディターです。製品のコアな部分における大きな変化であることが想像できるでしょう。Confluence はまた私たちのイントラネットとしても使用しており、通常は Confluence の最新マイルストーンを動かし、リリースのドッグフーディングを行っています… Confluence 4 を除いてですが。なぜ Confluence 4 を使用していないのかとあなたは質問するかもしれませんね?それは、もし重大なバグが発見された場合、新しいバージョンをデプロイするのに時間がかかりすぎてしまうからです。そして、イントラネットは私たちのビジネスのコアですから、バグ修正された新しいバージョンの Confluence がデプロイするまで 2 時間も待つことはできません。しかし、継続的デプロイにより、この問題を解決することができました。コードをチェックインするところから、それを本番環境で動作させるまでの全てのプロセスを自動化しました。

ContinuousDeployment.pngプロセスを構築