「標準化といってツールの選定はしても、プロセスの標準化には至っていない」――日本IBMの森田氏はこう話し、「開発−ビルド−テスト」フェーズのプロセス管理を行うことで自動化/最適化を図っていく必要性を述べる。
ビルドに失敗していたため、次のビルドが通るまでテストチーム、リリースチームは待機。長時間掛かるようなビルドが途中で失敗したことに気づかず、時間を無駄に過ごしてしまうビルドチーム――程度の差こそあれ、多くの開発現場で見られる光景だ。
大規模開発でしばしば指摘される問題として、開発ライフサイクル、特に「開発−ビルド−テスト」フェーズのプロセス管理が成熟していないことがこうした光景を生み出す背景として挙げられる。ビルド、テスト、リリース(もしくはデプロイ)、ソース管理、変更管理と個別で見てみれば、確かにツールも充実し、多くの部分が自動化できるようになった。しかし、開発プロセスすべてを見通し、自動化/最適化を図ってくれるような機能を提供するツールは数が少ない。
「隣のチームは別の工程管理ツールを使っていたり、そもそも開発言語が異なっていたりするので、標準化は難しい。標準化といってツールの選定はしても、プロセスの標準化には至っていないですし」と話すのは、日本IBMソフトウェア事業ラショナル・テクニカル・セールス副主任ITスペシャリストの森田成紀氏。
同氏は続けて、「ビルドプロセスの問題は、属人的でかつ手作業の工程が多いこと。シェルスクリプトなどで部分的な自動化はできるが、工程をまたいだ部分を自動化しようとすると、それでは立ちゆかなくなる。工程単体ではなく、前後の工程とのギャップを埋めなければ開発チームとしてはボトルネックを内包したままでしかない」と説明する。
「開発/ビルド/テストフェーズのプロセスをどう自動化/最適化するか」「ビルド、テスト、デプロイといった各チームの手作業での連携をどう効率化」が求められていると森田氏。そうした課題を解決するのがIBM Rational Build Forgeであるという。
IBM Rational Build Forgeは、ソフトウェアの配布プロセスを自動化するビルド管理とリリース管理のためのツール。IBMが2006年5月にBuildForgeを買収した結果、Rationalブランドとしてリリースされるようになった。最新版は7.0.2となる。
ソース管理、変更管理、テスト、ビルド、デプロイもしくはリリースといった工程間の情報を集約することで、プロジェクトの状態を可視化する同製品は3層構造のアーキテクチャで構成される。
ソース管理やビルド、テストなどを行うサーバにはBuild Forgeエージェントを入れ、管理サーバへアウトプット/ログ、環境構成などを送るほか、後述するプロジェクト、ステップの実行を伝える。なお、POSIX準拠のコンパイラが入っている環境を用意し、そこにエージェントを入れることで、ビルドファームを拡張することももちろん可能となっている。
データベースとアプリケーションサーバで構成される管理サーバでは、プロジェクト、ステップ、エージェントが入ったサーバのサーバ構成(環境構成含む)、ユーザー/権限情報、ビルドの統計などがデータベースに格納され、一元的に管理される。
その管理サーバに対して、Webブラウザ経由もしくは統合開発環境(要プラグイン)からアクセスするという形となる。
ステップごとのビルド状況などはリアルタイムでこの管理コンソールから確認できるほか、各担当者に通知するよう設定できるため、ビルドエラーなどに気づかず放置、といったこともなくすことができる。
また、J-SOX法などの法令に準拠するため、ビルドに関連する情報――障害管理ツールやテストツールがどういった処理を行ったか、ビルド成果物のMD5チェックサム――は記録できる。一連の工程を管理するだけでなく、ドキュメント化していくことは監査の観点からも今後求められる機能となる。
森田氏は「こうした工程間の自動化はあくまで入り口」と話す。ステップを実行すれば、それぞれの平均実行時間など詳細なパフォーマンスリポートが生成される。これを基に、並列実行が可能なビルドプロセスはないか、手順の組み替えるのが効果的ではないかなどを再考し、全体の最適化を進めていくのが理想となる。
「例えば、リポートでミスが発生しやすいと思われるようなステップに、チェックのステップを入れるだけでも、全体の効率は改善されていく。単に自動化を行うだけでは現状とそれほど変わらない。それをどう最適化していくかを支援するのがBuild Forge」(森田氏)
大規模な開発になればなるほどサイロ化しがちな開発チーム。そのチーム間の連携を強化するBuild Forge。IBMもまた、その恩恵を感じている。多くの製品を抱え、それぞれのプラットフォームごとにパッケージをリリースしていかなければならない同社。開発拠点は分散し、ビルドシステムもプラットフォームごとに存在している。スイート製品をビルドする際は、24時間掛かるという状況で、1度ビルドに失敗してしまうと、リリースチームは丸一日手持ちぶさたとなってしまっていた。Build Forgeの導入後、ビルドは3時間にまで短縮された。
「開発においてサイロ化しがちなチームの問題は、解決できないと一般には思われている。現在の状況は、統合ビルドの担当者が“人間Build Forge”と化してリソースの最適化を図ろうと孤軍奮闘しているような状態。Build Forgeにそこを任せ、本来の業務である開発作業に専念してもらいたい」(森田氏)
Copyright © ITmedia, Inc. All Rights Reserved.