目次


継続的インテグレーションによってソフトウェアの開発をより迅速に行えるようにする

IBM SmarterCloud Enterprise をフレームワークとして使用した継続的インテグレーションのプラクティスを検討する

Comments

IBM SmarterCloud Enterprise は、IBM が所有し、運用するクラウド・サービスです。IBM では世界各地の施設で数々のクラウド・コンピューティング環境およびイニシアチブを展開していますが、クラウドに期待される重要な特性であるマルチテナンシー、セルフサービス、使用量に基づく料金設定、そしてすぐに使用できる仮想ソフトウェア・イメージの提供を組み合わせた、IBM 初のクラウドによる商用サービスは「開発&テスト」です。つまり、マルチテナンシー、セルフサービス、使用量に基づく料金設定、そしてすぐに使用できる仮想ソフトウェア・イメージにサポートされた「開発&テスト」こそが、IBM の商用サービスを代表します。

IBM SmarterCloud Enterprise チームのメンバーであるこの記事の著者たちは、開発者およびテスターたちがソフトウェアの効率性と品質を高められるように、クラウド・サービスを利用して継続的インテグレーションを適用しています。

重要な課題

一般にソフトウェア開発プロセスでより効果的なのは、開発者が自分専用の環境でコーディングや問題のデバッグを行えるようにすることです。けれども、開発者ごとの開発環境は、共有されている統合テスト環境にコードをデプロイする際のコストを増やすことになるのが通常です。開発者が独自の開発環境で作業をすれば、できるだけ早い段階で問題を見つけられるでしょうが、そのような環境の構築と保守を困難にする問題はさまざまにあります。

第一の問題は、環境が次第に複雑になってくることです。私たちのプロジェクトでは、最も単純な構成だとしても、11 台以上のサーバーに 13 個以上のコンポーネントがインストールおよびデプロイされます。この環境を完全に構築するにはかなりの時間とリソースが必要になるため、開発者が期限までに環境を構築できないことは珍しくありません。

第二に、保守しなければならないバージョン、そして開発しなければならないバージョンが次第に増えてくるという問題があります。開発者は、最新の環境で最新のコード・レベルに対して新しい機能を実装する必要があり、さらには前回の環境で前回のコード・レベルに対してサポートおよび欠陥の修正をしなければなりません。また、テスターにも、スケジューリングされたプランに従ってテスト・ケースを実行するための環境、クライアントの緊急サポート用の環境など、異なる複数の環境が必要になります。さまざまなバージョンに対して異なる環境をすべて保守し、それらを多数の開発者に配布するのは容易なことではありません。

さらに、数多くのイメージを保守するにはコストもかかります。環境とバージョンの数が増えるにつれ、物理環境に伴うコストも同じように増えていきます。担当者を増員する必要があるだけでなく、環境が増えると、それだけスペース、ハードウェア、電力、冷却装置も余分に必要になります。

エクスペリエンス

開発者ごとに環境全体を提供しなければならない場合、開発環境にかなりのコストがかかる可能性があります。それよりも賢い方法は、コンポーネントを共有の環境と専用の環境に分けることです。一部のコンポーネント (データベース、データ・ステージ・コンポーネントなど) は、異なるバージョンで作業している複数の開発者の間で共有することができます。一方、データベース・サーバー、WebSphere サーバー、Web サーバー、TAMeb (Tivoli Access Manager for e-Business) などのコンポーネントは共有することができません。サーバーの使用効率を高めるためには、下位レベルのアクセス・フローのことを考慮すると、複数のコンポーネントを 1 台のサーバーにまとめて配置するのが望ましいです (1 台のマシンにデータベース・サーバー、WebSphere サーバー、Web サーバーを配置し、別のマシンに TAMeb を配置するということです)。そうすることで、コストを大幅に削減することができます。

IBM SmarterCloud Enterprise を使用すれば、複数のサーバー (Linux 32 ビットおよび 64 ビット、WebSphere、DB サーバーなど) をプロビジョニングすることができます。IBM SmarterCloud Enterprise から要求されたサーバーを基に、コンポーネントのインストールおよびビルドのデプロイメントが自動スクリプトによって行われます。

環境が構築された後は、ビルド検証テストを使用してその環境を検証してから、IBM SmarterCloud Enterprise に用意されているイメージ作成機能を使用して、その環境を新規イメージとして作成します。IBM SmarterCloud Enterprise では、パブリック・イメージを基にサーバーをプロビジョニングできるだけでなく、プロビジョニング済みサーバーをカスタマイズして新しいプライベート・イメージを作成することもできます。

開発者にそれぞれ専用の環境を提供しなければならない場合には、IBM SmarterCloud Enterprise を利用して、プライベート・イメージを基に新規サーバーをプロビジョニングすることができます。プロビジョニングにかかる時間は、わずか数分です。特定のバージョンの環境を提供するという要求を満たしたら、開発者はコードに加えた新しい変更をデプロイして、その結果を検証する作業を効率的に行うことができます。

テスト・チームがテスト・ケースを実行する場合、通常は環境全体が必要になります。この場合も、上述した開発者が環境をプロビジョニングする場合と同じような方法で対処することができます。

サーバーが必要なくなった場合には、IBM SmarterCloud Enterprise に用意されている削除機能を使ってリソースを解放することができます。

IBM SmarterCloud Enterprise では、他にもさまざまな方法で実際の開発プロセスの効率を高めることができます。例えば、以下の方法です。

  • ミドルウェアおよび構成からなる環境を作成し、その環境をプライベート・イメージとしてビルドすることはせずに、テンプレートとして保守します。
  • 最新の環境を提供できるように、日次ビルド用のプライベート・イメージを作成します。

図 1 は、この環境構築プロセスを説明した図です。

図 1. 環境構築プロセス
環境構築プロセス
環境構築プロセス

図 2 に、ローカル環境 (開発者独自の環境) を改良する様子を示します。

図 2. ローカル環境の改良
ローカル環境の改良
ローカル環境の改良

図 3 に、環境提供のライフサイクルを示します。

図 3. 環境提供のライフサイクル
環境提供のライフサイクル
環境提供のライフサイクル

目に見える成果

IBM SmarterCloud Enterprise が提供するサービスをベースに継続的インテグレーションを実施すると、開発者とテスターの作業効率が飛躍的に改善されます。これにより、以下のメリットがもたらされます。

  • 複雑な環境が単純な環境に改良されることにより、開発者のそれぞれに独自の環境を提供しやすくなります。
  • コードの品質が向上し、欠陥の発生率が低くなります。短時間で環境を用意できるため、開発者がリソースの入手を待って無駄な時間を過ごすことがなくなるとともに、コードをチェックインする前に自由にコードをテストして、発生した欠陥の根本原因を突き止めることができます。
  • 開発者たちがコードの変更を即時に共有することができます。個々の開発者が独自に作成した新機能のソース・コードを含めたプライベート・イメージを取り込むと、他の開発者たちは、コード変更が含まれるそのプライベート・イメージをベースにインスタンスをプロビジョニングすることができます。
  • 環境の特定のバージョンを短時間で開発者およびテスターに提供することができます。これまでは特定のバージョンの環境を用意するまでにある程度の時間が必要だったものが (以前のバージョンの場合には特にそうでしたが)、ほんの数分で用意できるようになります。
  • 必要となる人的リソースが少なくなります。環境を用意するのは面倒な作業になりがちで、通常は相当な時間が必要ですが、継続的インテグレーションを実施することで、人的リソースをこのようなお決まりの作業から解放し、重要なタスクに専念させられるようになります。
  • 必要となるハードウェア・リソースも減ります。サーバーは、不要になった時点で解放することができます。

ここからは、2 つの例を検討しましょう。

例 1

例えば、3 つの主な役割で構成されているチームがあるとします。具体的には、1 人のビルダー、40 人の開発者とテスターです。

以下のプロセスは、ビルダーが日々行うタスクです。

  1. ビルドを要求します。
  2. ビルド要求が失敗した場合、Rational Team Concert のビルド・ログを調べて、ビルド・エラーまたはコンパイル・エラーが発生したかどうかを確認します。このタスクには、相当な時間がかかります。
  3. ビルドをデプロイします。パッケージをインストールして構成し、サーバーを再起動して変更を適用します。
  4. ビルド検証テスト (BVT) を行います。
  5. BVT レポートに問題が示されている場合、ビルダーはログを調べて、問題の修正を試みるか、あるいは開発者に修正を依頼します。

BVT が完了すると、次は開発者とテスターがローカル環境にビルドをデプロイします。このタスクは、ビルダーが行うタスクと同じです。したがって、ビルダーの場合と同じコストと時間がかかりますが、このタスクが完了してからでないと、開発者とテスターは自分たちの作業を始めることができません。

この説明からわかるように、第一の問題は、開発者とテスターはビルダーと同じタスクを行うため、ローカル環境で作業を行えるように準備をしなければならないことです。ローカル環境で作業するための準備には相当な時間がかかり、開発者とテスターにとって余計な手間がかかります。

第二の問題として、開発者とテスターのローカル・マシンは、ビルダーがビルドをデプロイするサーバーよりも処理速度に劣るのが通常です。したがって、開発者とテスターがビルドをデプロイする際のコストを、ビルダーによるデプロイメント・コストと同等に見積もるのは正確ではありません。実際の時間コストは、ビルダーのコストよりも高くなります。

第三に、開発者とテスターの全員がビルドをデプロイする必要があるということは、それだけ失敗の可能性が高くなるということです。失敗した場合、エラーを修正するための時間がさらに必要となります。

開発者とテスターは、以上の追加タスクを完了してからでないと、自分たちの作業を始めることができません。開発者とテスターのパフォーマンスに影響が出た場合、さらに大幅な時間とリソースが必要になります。しかも、開発者が新しい機能を実装したとすると、その環境は他の開発者と共有できなくなってしまいます。他の開発者がその新しい機能をベースに開発する場合や、ユニット・テストを行う場合には、新しいビルドをデプロイする必要があるため、またさらに時間がかかることになります。

IBM SmarterCloud Enterprise を使用すると、結果はまったく違ってきます。

まず、ビルダーが行う上述のタスクは基本的に同じですが、ステップ 2 とステップ 4 は、IBM SmarterCloud Enterprise のインスタンスで行うことができます。また、ビルダーが行わなければならないタスクが 1 つ追加されますが、それほど時間のかかるタスクではありません。その追加されるタスクとは、インスタンスをプライベート・イメージとして取り込み、そのイメージを開発者およびテスターと共有することです (図 4)。

図 4. 日次ビルド用インスタンスからプライベート・イメージを作成する
日次ビルド用インスタンスからプライベート・イメージを作成する
日次ビルド用インスタンスからプライベート・イメージを作成する

このステップによって時間コストが追加されるように思えるかもしれませんが、ビルダーの時間コストが増える代わりに開発者とテスターのタスクは単純化されます。それは、ビルダーによって共有されたプライベート・イメージからインスタンスをプロビジョニングできるためです (図 5 を参照)。

図 5. プライベート・イメージからインスタンスを追加する
プライベート・イメージからインスタンスを追加する
プライベート・イメージからインスタンスを追加する

これが完了すると、開発者とテスターは自分たちの作業を始めることができます。この場合、開発者とテスターはローカル環境で作業するための準備が必要なくなるため、そのためのコストを節約することができます。しかも、ビルドをデプロイする必要もありません。したがって、パフォーマンスの低下やエラーの修正作業が発生することはなく、インスタンスをプロビジョニングするための時間コストもわずかです。

開発者が新しく作成した機能を他の開発者と共有する場合には、ビルダーと同じことをする必要があります。つまり、インスタンスをプライベート・イメージとして取り込み、そのイメージを共有します。このようにすれば、他の開発者が作成した新しい機能をベースに作業するときには、共有されている新しいイメージからインスタンスをプロビジョニングするだけで済みます (図 5 を参照)。新しいビルドをデプロイする作業に時間を余計に費やす必要はありません。

これで、IBM SmarterCloud Enterprise を使用することで、開発者とテスターにメリットがもたらされることが明らかにわかるはずです。開発者とテスターは、インスタンスをプロビジョニングするためにわずかな時間をかけさえすれば、すぐに自分たちの作業を始めることができます。したがって、チームのパフォーマンスが改善され、生産性が向上するというわけです。

例 2

2 番目の例では、チームが取り組んでいるプロジェクトに、DailyBuild20110507_R1.4 と DailyBuild20110507_R2.0 という複数のリリース・バージョンのビルドがあることを前提とします。

開発者とテスターは、両方のビルドで同時に作業しなければなりません。従来の手法では、それぞれのビルドに応じた複数のローカル環境を保守しなければならないため、例 1 で説明したように時間とリソースのコストが増えることになります。

さらに、チームに新しく加わったメンバーには、ローカル環境を保守する方法を学ぶための時間が必要です。これらの問題のすべてが、プロジェクトの進行を遅らせます。

IBM SmarterCloud Enterprise を使用すると、事態は一変します。すべての保守コストは排除されます。それは、新しくメンバーが加わった場合でも同じです。ビルダーは、IBM SmarterCloud Enterprise で日次ビルド用のイメージを取り込んで共有します。開発者やテスターが特定のビルドで作業しなければならない場合、必要となる作業は、その特定のイメージ (例えば、図 6 に示されている DailyBuild20110507_ R 1.4) からインスタンスを追加することだけです。

図 6. 特定のビルドからインスタンスを追加する
特定のビルドからインスタンスを追加する
特定のビルドからインスタンスを追加する

その上、作業が終わった後にそのインスタンスが必要なくなれば、開発者やテスターはインスタンスを解放することができます。したがって、保守コストが排除され、プロジェクトに効率性およびコストの改善が見られるようになります。

次のステップと推奨事項

継続的インテグレーションには多くのメリットがあります。これらのメリットが得られるようにするには、開発者とテスターに極めて迅速に環境を提供しなければなりません。環境の複雑さから、開発者に提供する環境をより有効に改良し、開発者ができるだけ早い段階で統合を実行できるようにする必要があります。

より効率的な方法は、環境を共有リソースと専用リソースに分離することです。30 人の開発者がいる場合、サーバーの数を 3 台から 2 台に減らすことができれば、環境リソースを節約することになり、したがってコスト削減に役立ちます。

さらに、コンポーネントの数が多いということは、潜在的な問題がそれだけ多いということでもあります。環境内のコンポーネントの数を減らせば、開発者がその専門とする領域に専念できるようになります。さまざまなミドルウェア・コンポーネントと複雑さのレベルを検討することが、継続的インテグレーションをサポートします。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Cloud computing
ArticleID=821313
ArticleTitle=継続的インテグレーションによってソフトウェアの開発をより迅速に行えるようにする
publish-date=06212012