チーム開発に向けたビルド環境の構築開発プロセス再入門(5)(1/3 ページ)

  前回「反復計画のたて方」は、反復の計画について説明しました。今回は、ビルドとリリースの手順を具体的に説明し、ビルド担当者の責務を明らかにしてみましょう。

» 2004年08月17日 12時00分 公開

ドメインの分析と設計

 さて、本連載の最初で、この文章中ではソフトウェア開発の上流工程には注目しないと書きましたが、まったく言及しないのでは私の同僚に何をいわれるか分かりませんので、簡単に触れておきます。最初は、優秀な人・作ることができる人が、少人数で取りあえず動くものをわーっと作ってしまわなくてはいけません。かの論文「伽藍とバザール」でも、バザール方式においてはまず動くものがないと開発を始めることができない、と論じています。必要なロールは「優秀な人」、責務は「ドメイン分析・設計・実装」です。以上!

ビルド環境の構築

 さて、無事に最初のビルドのインプットとなるソースコードを記述することができました。このインプットを統合してビルドする手順を説明しましょう。

 ソフトウェアの開発プロセスの中でも、ビルドのプロセスは非常に重要なものです。今日では、高度なGUIを備えたIDE(統合開発環境)を使って開発を行うのが一般的です。例えば、C++ならMicrosoft Visual C++、Metrowerks CodeWarriorやBorland C++ Builder、JavaならEclipse、 Sun ONE Studio/NetBeans、Borland JBuilder、ほかの言語でもMicrosoft Visual BasicにBorland Delphiなど、本当にたくさんの種類のIDEがあります。これらは豊富なデバッグ機能を持っていて、大変に開発作業がしやすいものです。

 しかし、日々の開発作業のために各開発者が自分のマシンでソフトウェアを1日に何度もビルドするのとは別に、すべての開発者の成果物を統合してビルドする環境が必要になります。ビルドを行うとは、単にコンパイルをするという意味ではありません。ビルドには、次のような作業が含まれます。

 ビルドの作業
 ビルド番号を更新する
 構成管理ツールから、最新のソースコードを取得する
 ソースコードをコンパイルする
 ソースコードからドキュメントを生成する
 配布パッケージを作成する
 ビルドのインプットとなったファイルにタグを打つ
 xUnitなどで自動化されたテストを行う
 開発チームに候補ビルドをリリースする
 ビルドの成果物を保存する
 QAチームにビルドをリリースする

 

 このほか、IDLコンパイラなど、複数の種類のコンパイラを動かさなければならない場合もありますし、開発言語によってはリンクという作業も必要です。このとき、各ファイルやサブプロジェクト間の依存関係を管理して正しい順序で作業を行う必要があります。また、ビルドの完了を音やメールで通知したいこともあります。

 このようなビルド環境は、ビルドを行う専用のマシンを用意し、その上に構築するのが普通です(CVSのような構成管理ツールのサーバを稼働させるマシンと同じマシン上に構築することも多いでしょう)。このマシンをビルドマシンといいます。そして、このビルドマシンにおいてはIDEによらずにビルドできる環境を構築しなければいけません。ビルドを行ううえで一番重要なのは、コンパイルオプションやファイル依存関係などの構成(configuration)の管理ですが、IDEで統合ビルドを行ってしまうと、この構成の管理が困難になってしまいます。また、ビルド担当者が風邪で休んだりしてもほかの人がビルドできるようにしておくという観点からも、ビルド専用のマシンを用意しておくことは有用です。

 各開発者の作業用プロジェクトファイルのテンプレートとして、IDEのプロジェクトファイル(Microsoft Visual C++なら.dspファイル、Borland Delphiなら.dprファイルなど)を構成管理ツールにコミットしておくのは良い考えですが、IDEで統合ビルドを行うのは避けた方が賢明です。IDEの種類によっては、ビルドの構成・設定を保存するプロジェクトファイルが(人間にとって)ものすごく読みにくかったり、バイナリ形式になっているために変更の追跡が不可能な場合もあります。また、コンパイルオプションを1画面(ダイアログ)で表示できず、最終的にコンパイラに渡されるパラメータが何であるのか確認できないIDEもあります。そもそもビルドをするためだけにいちいちIDEを起動して、ウィンドウメニューから[ビルド]を指示するのはおっくうです。

 そこで、コマンドラインで動作するビルドのためのツールが必要になります。このツールは、要件として上に挙げた作業を行える必要があります。「外部コマンドを起動するだけなら、バッチファイルでいいんでないの」というなかれ。確かに、バッチファイルやシェルスクリプトを使って、ビルド環境を構築することはできます。しかし、ビルドツールの最も大事な仕事はファイル間やサブプロジェクト間の依存関係を管理することであり、これはバッチファイルやシェルには荷が重い仕事です。

 幸いなことに、このようなツールは昔からあります。伝統的な、歴史のあるビルドツールにmakeがあり、makeを使ってJavaのアプリケーションをビルドすることもできます。しかし、現在ではより洗練され、Javaの世界において事実上標準といえるビルドツールがあります。それがantです。antはmakeのような方言がなく、antのビルドスクリプトはまさにwrite once, run anywhereを実現した扱いやすいものです(ひと昔前は、Javaはwrite once, debug anywhereなどとやゆされたものでしたが!)。もちろん、antを使ってJava以外の開発言語によるソフトウェアをビルドすることもできます。

ビルド担当者の責務

 ビルド担当者は、各開発者が作成したソースコードをビルドして統合し、インストール可能な形にキッティングしてQAにリリースするまでの責務を負います。このため、ビルド担当者はインストール手順書を作成したり、インストーラが必要なソフトウェアの場合にはインストーラの開発も担当することがあります。もし、構成管理ツールにコンパイルできないソースコードがコミットされていたら、ビルド担当者は開発者をせっついて修正させなければいけません。

 「ビルド担当者」は、「開発者」や「QA」と同じく、ロールにすぎませんので、開発者もしくはQAが同時にビルド担当者であっても構いません。また、ビルド担当者は、製品をビルドする手順を文書化する責務も負っています。ビルド担当者は、ソフトウェア開発のプロセスを学習しやすい立場であるため、新人に担当させるとよい結果を生みやすいようです。ビルドのプロセスは、ソフトウェア開発プロセスの中でも非常に基本的で重要なプロセスであるため、これをきちんと理解するにも、一度はビルド担当者というロールを経験しておくべきです。ただし、品質の良いソフトウェアをビルドするには、品質の良いビルド環境が必須です。ビルド環境の構築はそれほど簡単な仕事というわけではありませんので、最初にビルド環境を構築する仕事を、すべて新人に任せるのは危険です。任せるふりをして、彼(女)を丁寧にフォローしてあげてください。

 次に、ビルドの手順をもう少し詳しく説明してみましょう。

       1|2|3 次のページへ

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ