コミットのメール通気

 

こんにちは、tracpathの便利な機能の紹介です。ソースコードの管理にバージョン管理システムを利用しているときチームメンバーのコミット(commit)を通知して欲しいと思ったことはありませんか。
Git / Mercurial / Subversion のリポジトリで開発作業をしているときチームメンバーのコミットを関係者にメール通知する機能をご紹介します。

 

tracpathはサポートしているバージョン管理システムに対応した柔軟でパワフルなリポジトリ通知機能を持っています。

 

リポジトリ通知の特長

 

リポジトリのコミット通知を受け取りたい場合は、リポジトリにチェックマークを入れるだけでコミット通知されます。これは、Git / Mercurial / Subversion すべてのバージョン管理システムで利用することが出来ます。

コミットを通知する設定

さらに大規模なリポジトリや大規模チーム開発で効果的に利用することが出来る、trunk(トランク)、branches(ブランチ)のパスを指定して特定のコミットのみを通知することが可能です。

例えば

  1. パスを指定する・・・trunk/,branches/ ディレクトリは以下のパスに対するコミット通知させることが可能
  2. ブランチ名を指定する・・・ticket や issue で始まるブランチ名をコミット通知させることが可能

リポジトリ毎のコミット通知設定

 

メール通知の設定方法

 

設定方法はとても簡単です。プロジェクトのリポジトリ毎に設定を行います。グローバルメニューの「個人設定」->「通知」をクリックしてください。

コミット通知の設定方法

 

メール通知される内容

 

開発中のリポジトリにコミットされると関係者にコミット通知メールが自動送信されます。
自動送信されるメールの例を以下に紹介します。ここではすべてHTMLメールになっていますが個人設定でテキストメールに変更することが可能です。

Git のブランチ master-0-2 を作成

git create

Git のブランチ master-0-2 を削除

commit-f11-git-delete

Git のブランチ master-0-2 を更新

commit-f11-git-update

Mercurial のコミット通知

commit-f11-mercurial-create

 

tracpathのコミット通知機能

 

 tracpathはリポジトリのコミット通知機能をだれでも簡単に利用できるようにし、開発を効率的にしたいと考えています。社内のリポジトリに便利な機能を設定したり、環境を構築したり、、、tracpathを利用すれば、開発者にとって必要な開発環境の整備や保守に時間を使う必要はありません。すこしでも自分たちの製品開発に時間を使って欲しいと考えています。

 コミットをメール通知するメリットとして、
エンジニア全員が他のメンバーの作業状況をリアルタイムに把握することでコードを多くの目に触れさせることに意味があると考えています。
ソースコードのコードレビューに繋がり、ソースコードの最適化アイデアやリファクタリングが議論されることを期待しています。

 すべては「よりよいソースコードにすること」と「製品の品質向上」に繋がると考えています。

ぜひ、リポジトリを利用されているエンジニアの方は「リポジトリのコミット通知機能」をご利用ください。


Gitによるクローズドなリポジトリサービス tracpath

qw

こんにちは、あなたの開発チームはどちらのバージョン管理システムを利用していますか。
Git でしょうか? Subversionでしょうか?

最近利用を開始したユーザーからは分散バージョン管理システムである「Git」「Mercurial」の利用やお問い合わせを頂きます。tracpath のサービス開始時は、Subversion のみに対応していたためSubversionを利用しているプロジェクトが圧倒的に多いのが現状です。

 

では、クライアントツールはどうでしょうか。

 

LinuxやCUIに慣れたユーザーは、Git,Subversionをすべてコマンドラインで操作した方が分かりやすいし、何よりも操作性、処理速度が速いという意見があり、クライアントツールとして利用します。

 

「ターミナル(コマンドライン)があればほとんど他のツールはいらない・・・」

開発者は毎日ソースコードにアクセスするためにバージョン管理システムを利用する事になります。

使い慣れたツールがもっとも開発効率が高くなるため新しく分かりやすいツールがリリースされても移ることは少ないと思います。

 

でも、初心者やバージョン管理システムを使い始めたばかりのユーザにとって、GUIを持つアプリケーションの使い勝手はとても良く、多くの便利な機能と視覚的なサポートがあり利用する人を増やしています。

 

結局、どのようなツールを使うかではなく、「何を開発するのか」「ツールで目的が達成できるのか」が重要になってくると考えます。

 

これからバージョン管理を使ってみようと思っている方を対象に、Gitのクライアントツールで有名な「TortoiseGit」と「Git Extensions」を使ったバージョン管理の基礎勉強(チュートリアル)とSubversionのクライアントツールで有名な「TortoiseSVN」の基礎勉強(チュートリアル)を紹介します。

 

このチュートリアルをレッスン1から実行することで、基本的なバージョン管理の機能を試すことが出来ます。チュートリアルは30分〜1時間くらいですが膨大なマニュアルを読む前に仕組みを把握することが出来ますのでぜひ挑戦してください。

 

Subversion:TortoiseSVN

TortoiseSVN の基礎勉強 ~ TortoiseSVN によるバージョン管理 ~

Git:TortoiseGit

TortoiseGit の基礎勉強 ~ TortoiseGit によるバージョン管理 ~

Git:Git Extensions

Git Extensions の基礎勉強 ~ Git Extensions によるバージョン管理 ~

 
 

 

こんにちは、皆様はバージョン管理ソフトウェアとして何を使っていますか。

tracpath はエンタープライズ向けの利用者が多く、Subversion がトップでその次が Git の利用者が多くなっています。

 

組込みシステム開発の現場

 

組込みシステム開発のお客様の中で何十年と開発が継続している製品のバージョン管理ソフトウェアとして、「CVS」を利用されているお客様がいらっしゃいます。

 新しいプロジェクトは tracpath の Subversion 環境をご利用頂いていますが、過去から継続している CVS プロジェクトだけはできない理由があるようです。担当者としては新しいバージョン管理の優れた機能を利用したいため「Subversion」や「Git」を使いたいと声をあげるのですが、管理側からは

「膨大なCVSリポジトリを他のリポジトリに移行(変換)したとき、だれも品質を保証してくれない」

という理由でなかなか踏み切れないと聞いたことがあります。

 

この問題以外にもバージョン管理システムを切り替えるリスクは存在しています。

 

まずは新規プロジェクトで新しいバージョン管理サービスを利用して徐々に移行することをオススメしています。

バージョン管理の初心者用コンテンツ

 

今回は、初心者向けに「CVS リポジトリを別のリポジトリに移行する方法」「SVN/Git/Mercurial リポジトリを別のリポジトリに移行する方法」の記事を公開しました。

リポジトリの変換用のツールも提供されており比較的簡単に移行できることがおわかりだと思います。

エンタープライズ向けの大規模なリポジトリの移行サービスを行っておりますのでまずはこちらよりご相談ください。

 

リポジトリ変換方法まとめ

 

移行先リポジトリ
移行元リポジトリ CVS SVN Git Hg
CVS n/a cvs2svn
一括変換
cvs2git
一括変換
hg convert
逐次変換
SVN manual
手動変換
n/a git-svn
一括変換
hg convert
逐次変換
Git manual
手動変換
manual
手動変換
n/a hg convert
逐次変換
Hg manual
手動変換
manual
手動変換
manual
手動変換
n/a

表中の各項目は、上から順に使用するコマンド、変換方法、難易度を表しています。

コマンド cvs2svn CVS→SVNリポジトリ変換コマンド
cvs2git CVS→Gitリポジトリ変換コマンド
git-svn SVN→Gitリポジトリ変換コマンド
hg convert Mercurial拡張コマンド
manual 移行元、移行先のバージョン管理ソフトウエアのcheckout/importコマンド
変換方法 一括変換 移行元のリポジトリを全て一括変換できる。
逐次変換 移行元のリポジトリを個別に変換できる。
手動変換 移行元のリポジトリをチェックアウトして、移行先にインポートする。
難易度 簡単に変換できる。
少し手間が掛かるが、変換できる。
変換が不安定なことが多い。

詳しい説明は以下のサイトで説明していますのでご覧下さい。「CVS リポジトリを別のリポジトリに移行する方法」「SVN/Git/Mercurial リポジトリを別のリポジトリに移行する方法

 

 

こんにちは、tracpath の重要な機能にソースコードの構成管理(バージョン管理)機能があります。
tracpath のバージョン管理機能は、Subversion(SVN) / Git / Mercurial を利用する事が出来ます。

あなたのチームでバージョン管理ソフトウェアを利用されている方もこれから利用を検討している方も参考になる記事を公開しました。

バージョン管理の歴史はそれなりに古く、RCS(Rivision Control System)が1982年に登場してから、30年余りが経過しています。オープンソースソフトウエア(OSS)の Apache Project や、FreeBSD Project などを中心にさまざまなバージョン管理ソフトウエアが開発されています。ソースコード管理に最適なバージョン管理ソフトウエアとして有名なソフトウェアのインストールから基本的な使い方を説明しています。

構成管理の基本

エンタープライズでもよく利用される4つのバージョン管理システムについてインストールから基本的な使い方を説明しています。自分にとって使い易いツールを見つけてください。
あなたのソフトウェア開発にとって必ず必要なバージョン管理システムの理解になればと思います。

  1. ソースコード管理に最適!バージョン管理ソフトウエアとは ~ 基礎学習 ~
  2. 「CVS編」バージョン管理システムを使ってみる
  3. 「Subversion編」バージョン管理システムを使ってみる
  4. 「Git編」バージョン管理システムを使ってみる
  5. 「Mercurial編」バージョン管理システムを使ってみる

CVS(Concurrent Versions System)

項目 説明
開発元 The CVS Team
最新版 1.11.23 / 2008年5月8日
最新評価版 1.12.13 / 2006年7月26日
プログラミング言語 C
対応OS UNIX系、Windows
種別 バージョン管理システム
ライセンス GPL
公式サイト http://www.nongnu.org/cvs

ref:WikipediaのCVS

Apache Subversion(SVN)

項目 説明
開発元 Apacheソフトウェア財団
初版 2000年10月20日(13年前)
最新版 1.8.1 / 2013年07月24日(4か月前)
対応OS クロスプラットフォーム
種別 バージョン管理システム
ライセンス Apache License
公式サイト subversion.apache.org

ref:Wikipedia:Apache Subversion

Git

項目 説明
開発元 濱野純, リーナス・トーバルズ, ほか多数
初版 2005年12月21日(7年前)
最新版 1.8.4.3 – 2013年11月8日
プログラミング言語 C, Bourne Shell, Tcl, Perl
対応OS Unix系, Linux, Windows
種別 バージョン管理システム
ライセンス GNU General Public License バージョン2
公式サイト git-scm.com

ref:Wikipedia:Git

Mercurial

項目 説明
開発元 Matt Mackall
初版 2005年04月19日(8年前)
最新版 2.8 / 2013年11月1日(36日前)
プログラミング言語 Python, C
対応OS クロスプラットフォーム
種別 バージョン管理システム
ライセンス GPL v2
公式サイト mercurial.selenic.com

ref:Wikipedia:Mercurial

 

Git Extensionsこんにちは、以前「[git] クローンからプルしてマージ、コミットしてプッシュする」分散バージョン管理がはじめての方に向けて、Git(ギット)の基本学習用チュートリアルを公開しました。

読んで頂いた方々からいろいろな要望を頂きました。
その中でも多くの方が Windows 環境で利用できる GUI クライアントツールの解説がほしい。という要望です。
Git の基礎勉強はコマンドベース(CUI)である Git をつかったバージョン管理の考え方と使い方を理解してもらうために作成しました。
バージョン管理の基礎を理解している人たちに向けて Windows 環境で利用できる GUI ツールのチュートリアルを作成しましたので公開します。

Git Extensions の基礎勉強 ~ Git Extensions によるバージョン管理 ~

Windows にて Git を使いたい方におすすめする Git Extensions のチュートリアルです。

dev_trace

tracpath によるプロジェクト管理は、ガントチャートやWBSなどの管理者向けに開発されたツールではありません。開発チームにとって生産性向上と効率化するための仕組みを持った開発現場のためのツールです。

そのため、予算の管理、人材管理のための機能はありません。しかし、開発者や開発チームに必要なプロジェクト管理機能とソースコード管理があります。

大小を問わず、すべての開発チームに必須なツール

  • プロジェクトのマイルストーン管理、タスク管理–簡単に実現できる仕組み–
  • バグ専用のデータベース–それもシンプルで、カスタマイズ可能–
  • バージョン管理システム–Git / Subversion / Mercural–

tracpath の強みである「課題がソースコードと連携していること」のメリットを説明します。
メリットは3つあります。
 

1. 開発のトレーサビリティ(追跡)

 

tracpath はあなたのプロジェクトの過去と現在の「なぜ」を理解するのに役立ちます。

以前に解決したバグに関連したファイルに作成された特定の変更を瞬時に見つけることが出来ます。これはプロジェクトの過去、現在含めすべての期間においてソースコードレベルで追跡することが出来ることを意味します。

プロジェクトの開始時点から現在までをタイムマシーンをつかって過去に移動することや特定の1地点だけを戻すことができます。

ソースコードをバージョン管理し、いつでも前のバージョンに戻すことが出来る安心感をあなたのチームに提供することが出来ます。

 

2. 開発のアクティビティ(活動)

 

プロジェクトの開発状況をリアルタイムに知ることが出来ます。開発状況を把握し、必要ならタスク・課題あるいはチェンジセット(コミットログ)を閲覧することが出来ます。

ソースコードのバージョン管理システム用に開発された tracpath リポジトリビューアーでは

  • コミット履歴
  • ソースコードの閲覧
  • 差分表示
  • リポジトリのログ
  • コードレビューとコメント

が統合された機能として提供しています。

バージョン管理システムのクライアントツールを使わなくても、またコマンドを覚えなくても、ブラウザのみで同様の情報を取得することが出来ます。だれでも、簡単に利用できる機能を提供することで開発者以外のチームメンバーにも価値ある情報を共有することが出来ます。

さらに詳しく説明してます。「ブラウザでソースコードの変更履歴を管理する「リポジトリブラウザ」機能」をご覧下さい。

 

3. 開発のスマートな連携

 

開発チームはソフトウェア開発に必要な多くのアプリケーションを利用します。アプリケーションの切替を最小限にすることは、時間の節約と思考の切替によるロスを大きく削減します。

tracpath はコミットフックに対応しています。コミットフックによって開発者は簡単な構文をコミットログにメッセージとして追加するだけでワークフロー上のアクションを実行すること出来ます。

 $svn commit -m "fixes #40 に対応しました。"
 や
 $git commit -a -m "fixed #41 に対応した"

 

git こんにちは、以前「[git] クローンからプルしてマージ、コミットしてプッシュする」分散バージョン管理がはじめての方に向けて、Git(ギット)の基本学習用チュートリアルを公開しました。

読んで頂いた方々からいろいろな要望を頂きました。
その中でも多くの方が Windows 環境で利用できる GUI クライアントツールの解説がほしい。という要望です。

Git の基礎勉強はコマンドベース(CUI)である Git をつかったバージョン管理の考え方と使い方を理解してもらうために作成しました。
バージョン管理の基礎を理解している人たちに向けて Windows 環境で利用できる GUI ツールのチュートリアルを作成しましたので公開します。

TortoiseGit の基礎勉強 ~ TortoiseGit によるバージョン管理 ~

Windows にて Git を使いたい方におすすめする TortoiseGit のチュートリアルです。

 

すべてのプロジェクトで必ずやっておくべき大切なことがある。それはプロジェクトのビジョンを共有することである。新サービスの開発プロジェクトやパッケージのバージョンアップ開発プロジェクト、顧客向けフルスクラッチのシステム開発などすべてでやるべき仕事である。

プロジェクトのビジョンを共有する必要がある人たちは、プロジェクトに関わる全ての登場人物であり、開発者、顧客・経営者、管理者である。プロジェクトのビジョンを文書として作成することで、このプロジェクトでチームが重視しようとしていることや目指していること、顧客の重視していることや優先順位がまとめられ、プロジェクトのビジョンとして共有される。このビジョンを確立して共有するときに関係者内の利害関係や力の関係でたくさんの意見が出るかもしれない。

関係者に共有することが思いの外難しく時間がかかるかもしれない。

でも、この工程はとても重要なので今使う時間はプロジェクトが佳境に入ったときに使う時間と同じくらい大切である。このビジョンはプロジェクト計画立案や要件定義等の工程でその土台になるべき重要な要素と考える。

私たちがプロジェクトのビジョンを策定するときのフォーマットは以下のようなタイトルが並ぶ。

これを雛形にして、プロジェクト管理者が作成するようにしている。

== ○○プロジェクトのビジョン
 1. 目的
 2. 要件
 3. 目標
 4. プロジェクトの進め方
 5. 予算・リソース・工数・スケジュール感

 

1. 目的

 
1. 目的

はじめにプロジェクトの背景や必要とされる理由が説明されるべきであり、プロジェクトをチームで進めていくためのベースの考えとして共有される目的を明示する。これによりチームは積極的な参加と正しいと思われる方向性を示すことがある。プロジェクトマネージャーが共感しやすい目的やビジョンを説明出来ることは、プロジェクトの価値を関係者に周知する強力なツールとなり、価値ある仕事と言うことを思い出させてくれる。
これまでプロジェクトのビジョン策定後、自分のチームに説明し顧客に説明することで、顧客自身がプロジェクトで達成したいこと、何を求めているのか、がはっきりすることが多々あった。

 

2. 要件

 
2. 要件

要件はプロジェクトに課せられることであり、顧客やチームが重視すべきことをまとめる。重視すべき点として予算内に収まるようにすべきか(コスト)、来年の2月までにサービスインすることか(期限)、現場の全ての声に対応した機能か、これらが複数定義されているか、を明示する。

私たちは箇条書きで思いつく要件を書き出し、優先度が高いと思われるリストに並び替えて整理したりする。

 

3. 目標

 
3. 目標

目標はプロジェクトで達成したいことーー自分たちのチームがこのプロジェクトを進める上で達成したいことーーを書いておく。

顧客の目的とは関係ない場合もある点を頭に入れておくべきである。

具体的な例として、すでに稼働しているシステムのバージョンアッププロジェクトでは「過去のコードのリファクタリングによるコードの最適化」「DBライブラリのバージョンアップ、チューニング」「Webアプリケーション用フレームワークのチューニング」などがある。その他にも「ペアプログラミングを実践」「コードレビューによるコードの品質を担保する」「テストの自動化ツールをプロジェクトに導入」などがある。

 

4. プロジェクトの進め方

 
4. プロジェクトの進め方

プロジェクトマネージャーを中心にプロジェクトのビジョンが策定され、成果物として必要なことが見えてくる。プロジェクトの進め方では、今回のプロジェクトにおいて最適と思われる開発方法ーーアジャイル開発?ウォーターフォール?ーーやチーム体制、責任の範囲、役割分担などが見えてくる。

自分のチームが得意としている方法・体制を明示する。

 

5. 予算・リソース・工数・スケジュール感

 
5. 予算・リソース・工数・スケジュール感

必須ではないがチームで共有できる場合、プロジェクトの予算、人的リソースーーだれが参加するのかーー、全体のスケジュール感(詳細なスケジュールはこれから計画されるはずであるが、おおよそのスケジュール感)を共有することは大切なことである。

 

さいごに

 

プロジェクトのビジョンはプロジェクト計画前に作っておくことをオススメする。プロジェクトが始まる前にマネージャーが時間を確保し作成することでプロジェクト管理の指針になる。

このプロジェクトのビジョンはプロジェクトが進行中も更新されチームメンバーに共有される。

当社ではいつでも見られるようにtracpathのWikiによりメンテナンスされている。

 
 

 

「開発チームの生産性を上げたい」「チームの情報共有化したい」「サービスの品質を上げたい」
プロジェクト管理ツールが解決すると謳っている課題である。ツールを導入したからといって生産性や情報共有化などの数値化しにくい点が改善した、と証明することは難しい。チーム全体が変わった気がする、前よりスケジュール遅延が少なくなったなどの感覚値で語られることが多い。

 

それなりの費用をかけてプロジェクト管理ツールを導入したけど、一部の人たちしか使っていない。数字をいじる仕事の人だけー管理者やリーダーのみーという声を聞く。

 

これまでいろいろな開発チームを見てきて、開発ツール等の選定、導入をサポートしてきた立場から
うまくいっている状態(チーム)に見られる特長として、チームのボトムアップでの盛り上がりとチーム全員がそれなりに使うことができる共通言語になる場(ツール)になれるかどうかだと思った。

 

ツールはあくまでもチームを成長させるためのきっかけにすぎないのではないかと思う。

 

医療業界向け業務サービスを提供している会社の話

 

医療業界向けに業務サービスを提供している約60名ほどの企業(エンド企業)でのこと。社内の基幹システム運用やホームページ、ウェブシステムの管理、運用まで4,5名の情報システム部が担当をしている。ただし、システム開発ができる技術者はおらず、外部にアウトソースしていた。開発会社として2社(A社、B社)といつくかのプロジェクトを進めていた。

2013110601

エンド企業ではSI企業で開発経験があり、システムに詳しく業務知識に明るい担当者が管理者(リーダー)として、すべての開発プロジェクトのとりまとめを行っていた。情報システム部門メンバーの進捗管理から外部の協力会社との仕様取り纏めなども管理しなければならず、いつも忙しい状態が続きそれが普通になっていた。

このまま何事も無くリーダーの管理で仕事はスムーズに進めばよいのだが、、、これまで体調不良で数日休むことがあり、業務に致命的な穴が空くことが何度か発生したらしい。

1人の優秀な人のスキルに頼り切った状態で運用されていたため、その人がいないというだけで情報システムメンバーは穴を埋めることが出来なかった。メンバーからするといきなりリーダーがやっていた作業を引き継いで進捗管理から外注管理まで・・・無理な相談である。

 

よし、ツールを導入しよう

 

開発チームの生産性向上、チームの情報共有に効果があると思われるツールを入れて試用版をいくつか試してみた。約1ヶ月試用してみたけど、メンバーは最初ちょっと使うだけ、いつのまにか見向きもされなくなってしまった。

ツールが役に立たない訳ではない。ちょっとしたリーダーの作業とチーム体制を変えたことでこの後、ーチームに導入、浸透するまで2,3ヶ月の時間が必要だったー一気にツールのメリットが享受されるようになった。

 

エンド企業の情報システム部門に必要だったこと

 

2013110602

新しい体制図では、これまで利用するツールが決められていなかったーメールに記載したり、Wordで書いたり、電話だったり..ーがツールを一元化しクラウドサービスに統一したことである。

外部の協力会社と一緒にプロジェクトの情報共有ができ、だれが、何をしているのかを見ることが出来る。

プロジェクトを進めるときに関係者が共有ツールを手に入れることでコミュニケーションコストの削減が実現ーコミュニケーションコストの削減は効率化に直結するーした。

これは、関係者で共通言語「今週中に対処が必要なレポートで進捗確認しよう」「#441 チケットにコメント書いたので、内容チェック後、コメントください。」「A社の提示した資料のチェックがまだです。いつまで?」が自然にできあがったためである。

もう一つ、重要な点はエンド企業の大きなシステム毎に専任の担当者を任命したことである。
社内の業務システム担当者とホームページやウェブシステムの担当者の2名である。

これによって、プロジェクトチームに推進力が生まれ数ヶ月後に多くの課題が解決されることになった。

まだまだたくさんの課題は残っており、体制とツールですべてが解決できたわけではない。

しかし、2,3ヶ月という期間でチームの風通しが良くなりプロジェクトが前に進んでいるという実感をチーム全員が感じていることはとても意義がある。

 

銀の弾丸はない、でもちょっとした改善で変わる

 

小さなチームのちょっとした改革によって前より少しだけよいチームになった。

この小さな改善のサイクルを繰り返すことがとても重要である。

はじめに

みなさんは、トラブルチケットという言葉をお聞きになったことはあるでしょうか。トラブルチケットは、問題発生時に発行される言わば受付票のようなもので、IT業界では障害管理を始めさまざまな用途で使われています。ここでは、アプリケーションのテストに不可欠な存在となったバグ追跡システムについて紹介するとともに、バグ追跡システムのユースケースについて紹介します。

バグ追跡システムとは

バグ追跡システム(BTS:Bug Tracking System)は、アプリケーションのテスト時や利用開始後に発生した障害を管理するシステムです。アプリケーションのリリース前に行われるテストは、アプリケーションの開発などに関わった関係者だけで行われますが、一度リリースしたアプリケーションが、数千から数万人規模で利用される場合、障害だけでなく、その他の問い合わせも利用者の増加とともに増えてくる事が予想されます。これらを人手を使って処理することも可能ですが、障害報告や問い合わせの件数が増えて来ると、人が対応していたのでは、対応や回答までのレスポンスが速くなったり、遅くなったりなど担当者の業務負荷に左右されることになります。しかし、バグ追跡システムを使うことで、利用者から受けたバグ報告や問い合わせ内容をシステムに登録し、受付番号(トラブルチケット)を発行することで、受け付けたチケットの受付日、受付時間、受付内容、完了日、担当者などの対応状況を一元管理できます。このように、バグ追跡システムでは、報告された内容をシステムに登録することで、未対応のチケットや解決に時間が掛かっているチケットなどチケットの状況をさまざまな角度から分析し、障害報告や問い合わせへの対応を通して、アプリケーションの品質改善などに役立てています。以下では、バグ追跡システムのユースケースについて紹介します。

2000-02

代表的なバグ追跡システム

フリーのバグ管理システムには、Tracや影舞のようにPythonやRubyで実装されたシステムの他に、BugzillaのようにPerlで実装されたシステムもあり、さまざまなシステムが公開されています。以下に、代表的なオープンソースソフトウエア(OSS)のバグ追跡システムを簡単に紹介します。

Trac(トラック)

Tracは、スウェーデンのEdgewall Software社が開発するプロジェクト管理システムです。プログラミング言語Pythonで実装されており、プロジェクト管理システムのサブ機能として、バグ管理システムが搭載されています。Wiki(ウィキ)などの情報共有ポータルサイトも構築できるため、プロジェクト関係者間で資料やさまざまな情報を共有できるため、大規模なプロジェクト管理に適しています。Tracは、LAMP(Linix,Apache,MySQL,PostgreSQL)環境だけで無く、殆どのUNIXマシンで動作します。

2000-03

Bugzilla(ばぐじら)

ウエブブラウザFirefoxで有名なMozilla Foundationが開発しているバグ管理システムです。プログラミング言語Perlで実装されており、日本語化も可能です。元々Netscape Communications社のウエブブラウザNetscapeのバグ管理のために作られたシステムのため、安定して利用できるシステムだと言えます。Tracと同様に、殆どのUNIXマシンで動作します。

2000-04

影舞(かげまい)

影舞は、Fukuoka Tomoyuki氏が開発したバグ管理システムです。プログラミング言語Rubyで実装されており、データベースが無くても動作する手軽さとソースコードの少なさが特徴です。2008年3月にリリースされたバージョン0.8.8が最新のバージョンであり、現在は開発を終了していますが、Bugzillaと同様に安定して利用でき、カスタマイズしやすいシステムだと言えます。Tracと同様に、殆どのUNIXマシンで動作します。

2000-05

ユースケース1:ソフトウエアの障害管理

ケース1は、ソフトウエアの障害管理です。バグ追跡システムは、ソフトウエアのバグを追跡するシステムですから、バグ管理に利用されるケースが最も多くなっています。フリーのUNIXであるFreeBSD Projectでは、1994年以降GNATS(GNU BUG TRACKING SYSTEM)というバグ追跡システムを利用しており、FreeBSDのユーザーは、send-prコマンドを利用して、FreeBSDのGNATSシステムに問題報告を送信できるようになっています。また、ウエブインタフェースを利用したバグ報告も利用できるようになっています。

ユースケース2:営業支援システム

ケース2は、営業支援システム(SFA:Sales Force Assist)への適用です。バグ追跡システムでは、報告日、報告者、報告内容、優先度、添付ファイル、プラットフォーム、バージョン、再現性などの項目を使ってバグ管理に必要な情報を登録します。この機能を営業管理システム用にカスタマイズすることで、訪問日、営業担当者、同行者、訪問先、営業内容、案件確度、添付ファイルなどを管理することができます。そのためには、バグ管理システムのカスタマイズが必要となりますが、今回紹介した影舞は、ソースコードの少なさからカスタマイズに適しています。

ユースケース3:QA管理システム

ケース3は、QA管理システムへの適用です。QA管理は、Yahoo知恵袋やOK Waveなどのように掲示板方式で実装されることが多いのですが、バグ管理システムをカスタマイズして利用することで、例えば登録された情報をCSV形式で出力したり、出力する項目もカスタマイズによって追加することができるため、掲示板方式のQ&Aシステムよりも柔軟なシステムを構築できます。

まとめ

ここまで、バグ追跡システムについて紹介するとともに、ユースケースについて紹介しました。オープンソースソフトウエアのバグ管理システムは、さまざまなプログラミング言語で実装されており、カスタマイズが必要になった場合でも、開発しやすい言語のシステムを選定することで、既存のシステムの機能拡張を行うことができます。今回紹介したユースケースをヒントに、新たなユースケースを検討してバグ管理システムを活用してみませんか。