Atlassian での継続展開

2011-04-07 (Thu)  •  By 伊藤  •  活用のヒント  •  Bamboo アジャイル開発 翻訳

今回の記事は、アトラシアン ブログ「Continuous Deployment at Atlassian 」の弊社翻訳版です。原文と差異がある場合は、原文の内容が優先されます。

“早めにテスト、何度もテスト”。この昔からのソフトウェア開発原理はテスト以外の多くの分野に適用できます。事実、頻繁に何かを行えばエキスパートになろうとしなくても徐々に上達していくものです。

旧来、ソフトウェアはウォーターフォール モデルで開発されてきました。このモデルではプロセスの各段階が順に次の段階に続いていきます。プロセスの最終段 階に近づくと、ある種の展開やリリースが見えてきます。これにはかなりの苦労が伴います。それはなぜか? リリースが発生するのは 1 年に 1 回程度 だからです。

チー ムはアジャイル開発手法を採用し、反復および増分開発プラクティスを実装することでこのリリース サイクルを減らし始めました。2 ~ 6 週おきにソフ トウェアの新しいバージョンを展開するため、展開作業が短くなっていきます。展開回数が多いほど上達していくことを思い出してください。2 週間おきに 行ったとしても、展開プロセスにいくつかの手動による手順があったり数時間かかることに不満は感じないでしょう。ところが、1 日に 20 回 展開作業を行うとしたらどうでしょうか? そこで本日発表したBamboo 3.0 の代表的機能である継続的展開の登場です。

継続的展開

継続的展開はコミットがすべて製品に組み入れられるわけではないことを意味します。業界や創り出す製品によっては、これが実現可能でないことがよくありま す。また、製品マネージャーとして言わせていただくと、対象となる人や変更の種類によっては製品を継続的に更新すると顧客の受けが良くないことがありま す。それでも、継続的展開からチームが得られる利点は多くあります。

現在 Atlassian では Confluence 4 用の新しいエディターの開発に取り組んでいます。まったく新しい XHTML バックエンドを 備えた完全な WYSIWYG です。これが製品の中核を大きく変更するものであることがご想像いただけると思います。また、Confluence は弊社のイントラネットの基盤となっ ており、通常は Confluence の最新マイルストーンを実行して自社製品のリリースを試しています。ただし Confluence 4 は実行し ていません。なぜ実行していないか? 致命的なバグが見つかったときに新しいバージョンの展開には時間がかかるからです。さらに、弊社のイントラネットは 事業の中核であるため、バグが修正された新しいバージョンの Confluence が展開されるまで 2 時間も待つことはできません。一方、継続的展開ではコードのチェックインから実稼働環境での実行までのすべての手順を自動化することでこうした問題を解決できます。

プロセスの構築は以下のように行っています。

コミット

機能がコミットされ、ビルドをトリガーします。ビルドは自動的にトリガーされるか、または自分で制御したい場合は特定のタイミングでビルドをスケジュールできます。

ビルドの各段階

ビルドは以下のようないくつかの段階を通じて実行されます。

  • コンパイル — これは Java やその他のコンパイル言語特有のものですが、一般的にアプリケーションを準備する段階です。
  • ユニット テスト — すぐに終わるためまずこれを実行します。ここで何か不具合があった場合は、次の段階に移行する必要はありません。
  • 承認テスト — 弊社では JUnit を通して自動テストを使用しています。テストをスピードアップするため、いくつかのバッチを作成して平行して実行します。
  • Selenium テスト — 同時に複数の環境に対して Selenium テストを実行します。
  • 展開 — UAT への展開はすべてのテストに合格した後に自動的に発生します。

手動テスト

新機能を製品に組み込む前に追加の手動テストを行います。QA チームはビルドをチェック アウトし、テスト内容を把握するために関連 JIRA チケット を確認します。展開テストでは、サービスを監視して異常動作がないかを確認することで重大な問題を見つけることができます。

実稼働環境への展開

QA チームがビルドに問題がないと判断したらボタンを押し、事前作成してテストし、UAT 環境に配置した同じ成果物を使用して次の展開をトリガーします。1 回 のボタン押しによる展開以外は、ライブ システムへの展開プロセスは完全に自動化されています (弊社の場合、実際に顧客にリリースするわけではありませ んが)。今後確実性が増したらこの要件を取り除いてプロセス全体を完全に自動化することも考えられますが、システムの負荷やその他のメトリックスに異常が 見られたらすぐに警告をトリガーできるような監視システムを配置しておくのが賢明です。

利点

偽りなく述べると、継続的展開は確かに回帰やバグを防ぐために大量の規律を必要とします。しかし、Eric Ries が指摘しているように、継続的展開の実装には 5 つのシンプルな手順に従うだけで十分です。継続的展開を採用することによる利点も多くあります。弊社の 場合、最大の利点は Confluence の最新バージョンを実際のリリースよりもずっと前に実行してテストでき、全体的に品質の高い製品に仕上げるこ とができることです。バグや回帰をかなり早い段階で見つけ、ほとんどの変更は小規模なため修正もずっと簡単です。リリース時には開発者に何時間も割いても らわなくてもボタンをクリックするだけで実行できます。


Related Articles

お気軽にお問い合わせください

お問い合わせ