「コードの共同所有」を成功させるためのノウハウ後編をお送りします。前回(CVSとEclipseで「コードの共同所有」)はCVSサーバのインストールまで解説しました。今回はクライアントにシフトして話を進めます。CVSクライアントにはEclipseを利用します。EclipseのCVS機能ならイージーかつアジャイルにコードの共同所有が行えます。なお、Eclipseのインストール方法などは、「オープンソースのEclipseは仕事に使える開発環境」を参考にしてください。本記事の解説では日本語化されたEclipse 2.0.xを前提としています。
EclipseからCVSサーバを利用するには、CVSリポジトリごとに「CVSリポジトリ・ロケーション」を設定します。「CVSリポジトリ・ロケーション」とはCVSリポジトリのブックマークのようなものです。
以上を記入したら「終了」ボタンを押します。無事CVSサーバに接続できたら「CVSリポジトリ」ビューでリポジトリ内を見ることができます。[+]をクリックしてリポジトリの中身が見られるか確認します。HEAD/CVSROOTの中身が見られれば、CVSを利用する準備は整いました。
HEAD:開発の本線(幹)のことです
ブランチ:ブランチとはHEADから枝分かれした別の開発ラインです
バージョン:ある特定の時点におけるモジュールのスナップショットです
プロジェクトをチームで共有するために、CVSリポジトリにEclipseのプロジェクトを登録します。このことをEclipseでは「プロジェクトの共用」といいます。共用されたプロジェクトはほかの開発者がチェックアウトできるようになります。これがコード共有の出発点です。
共用先のロケーションを選択します。
CVSリポジトリからプロジェクトを取り出すことを「チェックアウト」といいます。チェックアウトされたプロジェクトはローカルのワークスペースにコピーされます。開発者は常にローカルコピーに対して作業を行います。
別名チェックアウトを選べばチェックアウトディレクトリを指定できます。
Eclipseで各リソースのバージョンや状態を常に表示させておくことができます。画面がにぎやかになり、バージョンを意識しながら開発が行えます。
連載第1回の「XPな開発者の1日」を思い出してください。この1日の流れで主人公が使ったEclipseのCVS機能を解説します。
それではそれぞれの行動を詳しく見てみましょう!
【前日のモジュールの未取得分をCVS for NTサーバより取り出す】
仕事始め、前日にどこかのペアがコードを更新・新規追加しているかもしれません。まずは、リポジトリからワークスペースに最新のリソースを取り出して更新します。「何か作業を始める前はまず更新」というのが基本です。
Eclipseの操作は以下のとおりです。
リポジトリのリソースをワークベンチ内に取り込みます。また、表示されたリソースをダブルクリックすることで中身を確認できます。ワークスペース内のすべてのものをリポジトリと同じにするには、
これですべてリポジトリのものと置き換わります。
着信モード:ほかの場所で更新されたリソースを表示します
発信モード:ワークスペースで変更されたリソースを表示します
着信/発信モード:着信モードと発信モードの両方を表示します
【検索処理オブジェクトをCVSに追加する】
新規に作成したクラスをCVSに追加します。新規に作成したクラスにはもちろん対応するテストケースも先に作っているはずです。それも同時に追加します。
Eclipseの操作は以下のとおりです。
これで実際にCVSにコミットできます。[バージョン管理に追加]の操作を飛ばして、いきなり[コミット]しても構いません。その場合、[バージョン管理に追加]は自動的に実行されます。
【SearchServletを追加する】
これもまた、新規クラスです。【検索処理オブジェクトをCVSに追加する】と同様にコミットします。開発者の調子がいいみたいですね。新規クラスが次々とコミットされていきます。
【検索処理オブジェクト、SearchServletをリファクタリングしてコミット】
リファクタリングは常に行われます。リファクタリングとCVSの組み合わせで「コードの冷蔵庫」のような役割を果たします。食材(コード)のおいしい状態を保つようにみんなで監視します。
Eclipseの操作は以下のとおりです。
リファクタリング後のクラスはすでにバージョン管理されているものを触っているわけですから「バージョン管理に追加」の動作はいりませんね。
【M子ちゃんたちが作っていたクラスにコーディング規約と違うメソッド名が……。それも、修正してコミット】
デバッキング、リファクタリングなどをしていると、ほかの人が書いたコードを目にする機会が多々あります。そのコードが好ましくないときもあります。そのときは「人のコードだから」と気にせず、もっと良い状態に更新した方がよいでしょう。その方がプロジェクトのためになります。
しかし、そのときにリソースの競合が発生する場合があります。主人公とM子ちゃんが同時に同じソースに変更を加えた場合です。主人公は先にソースをコミットしました。M子ちゃんは、同じソースをコミットしようとしますが、すでにソースのリビジョンは上がってしまっています。この場合、自動的にマージを試みます。ほとんどの場合、マージがうまくいきます。しかし、主人公とM子ちゃんが同じ場所を修正していた場合、マージができません。これを「競合」といいます。
さてそこでM子ちゃんたちはコミットしようとして「“cvs コミット”コマンドの実行中にサーバがエラーを報告しました」とエラーを報告を受けます。エラーアラートの「< Eclipseの操作は以下のとおりです。 これでマージしたリソースがコミットできます。 どうでしょうか? コレで、経験6カ月のM子ちゃんも簡単に競合をクリアしました。他CVSクライアントで面倒だった競合もEclipseで簡単に解決、仕事をフリーズさせません。 コードの共同所有状態ではCVSのコミットが効率よく行われます。「コミット数=プロジェクトの元気度」といっても過言ではないでしょう。ほとんどコミットのないペアは問題を抱えています。声を掛けてみてはどうでしょうか? しかし、ルールを決めずに何も考えずコミットを連発するのは便利さを半減してしまいますので以下のようなルールを決めてさらに効率を上げることをお勧めします。 最低限守らなくてはならないルールです。ソースはコンパイルが通ってからコミットしましょう。出社して最新バージョンを取り込み後コンパイルエラーが出てしまっては、朝から気分が悪くなります。 コードとテストは対であるべきです。テストケースはクラスの仕様書代わりになります。仕様書の付いていないクラスは仕様が分からず、共同所有していくのが難しくなります。 テストが通らないということは仕様どおりではないクラスになっています。これも共有していくのが難しくなります。また、AntとCVSによる自動ビルド&テストを行っているチームでは、テストに通っていないことをブラウザでみんなに見られるのでショックです。 「コードの共同所有」では誰もがコードを修正できます。CVSのコメントは修正個所・意図の手掛かりとなります。 今回はコードの共同所有の意義とCVSについて学びました。これで料金所は通過しました。次はいよいよ高速教習です。次回はテスティングについて考えていきます。お楽しみに! この記事に対するご意見をお寄せください managemail@atmarkit.co.jp ▼縣俊貴(あがた としたか) メディアファイブ株式会社所属。XML,フレームワークを中心に開発業務に携わる。Javaのコミュニティー団体であるMobsterを主催。現在MonsterにてJavaベースのWikiシステム「MobWiki」を開発している。 ▼橋本正徳(はしもと まさのり) メディアファイブ株式会社所属。XML、フレームワーク等の開発業務に携わる。Javaのコミュニティー団体である「Mobster」を縣と共に発起、運営。現在mobsterにてバグトラッキングシステム「mobbug」等を開発している。「日本XPユーザーグループ関西支部 九州分科会」にも参加。ちなみにこの記事自身もCVSでバージョン管理し、縣と橋本とで共同所有されて書かれている。 ▼Project Mobster(ぷろじぇくと もぶすたー) 福岡県福岡市を中心にJava言語を研究追求し、その成果物をWeb上に公開していく団体です。年齢・スキル・会社などを超えてボーダーレスに活動しております。
■コミットに関してのルール
著者紹介
Copyright © ITmedia, Inc. All Rights Reserved.