私は会社のプロジェクトに取り組んでいる単一の開発者です。私は Subversion と Trac (バグ追跡と管理タイプとの通信用) を使用しています。ステージング サーバーと運用サーバーがあります。今日、いくつかのコードをチェックインしたところ、私の FSFS ベースの svn (v1.4) リポジトリが修復不可能なほど壊れていることがわかりました。これは非常に残念なことですが、VCS/ステージング システムをより最新のディストリビューション (現在は 2 年前のシステム) に移行する機会が得られました。(レポに関する限り、破損していない現在のバージョンのコードを持っているので、開発のすべての履歴とコメントは失われますが、コードは失われません。うわー。)

現在、私は Ubuntu で開発を行っており、本番環境では RHEL5-64 を実行しています。私のハードウェアは、32 ビット x86 シングルコア システムのままです。

私は SVN とそのコンストラクトに精通していますが、FSFS の破損の問題に少し焦っています。かなり人気があることを除いて、git についてはあまり知りません。私は現在 Trac を使用して問題を管理していますが、svn との統合がとても気に入っています。Git のサポートを有効にするプラグインがあるようですが、その開発の成熟度はわかりません。

現在、以下のようなものを作ろうと考えています。

1. Ubuntu 8.10 デスクトップ (そして apache2 やその他のパッケージを追加します...最後にサーバー エディションに GUI を追加しようとしたとき、私は髪を引っ張るしかありませんでした)
2. SVN (私はそれに精通しており、Git は 1 人のチームには少しやり過ぎのように思われるため)
3. Trac (私はそれに慣れており、SVN で動作するため)。

私の「新しい」VCS システムに関する提案と考えをお願いします。Git に移行する必要がある理由はありますか? Trac より「優れた」ものはありますか?

わかりました、Bugzillaは、平均的なエ​​ンド ユーザーからウィリーを怖がらせるでしょう。カマキリのようなものでさえ、初心者にとっては少し不気味です。

エンドユーザーや顧客がわかりやすい方法でバグを報告するのを簡単かつ直感的で、まったく威圧しないようにするために、どのような方法、Web パッケージ (推奨)、インターフェースなどを実装できますか?

私は、Bugzilla のように包括的で威圧的なものに必要な予備知識よりも、フォームベースまたはポイント アンド クリックのアイデアが好きです。

電子メールは、平均的なパンターにとって親しみやすいものですが、何が壊れているかを試して把握するために必要な種類の情報をユーザーに要求しないため、理想的とは言えません。

これまでのところ Bugs - Bug Genieは、平均的なユーザーが直面する最も恐ろしいオプションのようです。検索しましたが、私のような質問は見つかりませんでした。

提案、アイデア、洞察をお願いします！

コードベースに貢献するためにかなり大きなオープンソースプロジェクトに参加するかどうかを決定するとき、貢献するかどうかの決定にとって、プロジェクトの問題追跡機能 (つまり、バグや機能要求の追跡) はどの程度重要ですか?

まだ多くの重要な (巨大なコード ベース) オープン ソース プロジェクトがあり、それらは正式に問題追跡を行っていません - そして一部の貢献者は実際に雑多な「ToDo」リストの形で個人的にこれを行っているかもしれませんが、私は個人的には可用性の欠如と問題追跡の確立された使用が、組織、構造、およびプロジェクト全体の調整の欠如のかなり信頼できる指標であることがわかりました。

他の人は何を考えていますか？

私はフリーウェアの欠陥追跡ソリューションを探しています。Mercury Quality Centerの経験はありますが、5桁の値札が付いていると聞きました。個人的なプロジェクトのために何かが必要です。Webフォーム（つまりASP.NET）が望ましいでしょう。何か良いものはありますか？

VC、バグトラッキング、QA、単体テスト、展開、およびその他の類似したもの（計画/クライアント通信の側面を除く）に焦点を当てて、それほど高くないレベルでWebアプリケーションを開発するために使用するプロセスを説明してください。

私はこの分野で新しいので、私の大まかな例（読んでください：このプロセスを使用していません）は、いわば、間違いなく少し離れています-私が学ぶことができるように、それは欠陥であることを指摘してください。

例えば。

1. ローカルSVNサーバーにプロジェクトリポジトリを作成します。
2. DNSマッピング用のバッチ/シェルスクリプトを作成します。
3. プロジェクトをチェックアウトし、ローカル作業コピーの作業を開始します。
4. 機能をブランチとして開発します。
5. Mantisでバグを追跡します（リンクはSVN統合を通じてバグにコミットします（それが存在するかどうかはわかりません））。
6. あなたが行くように文書化します。
7. ブランチでQAを行います。
8. 安定したらトランクにマージします。
9. ユニットテスト？
10. 機能が実装されて安定したら、リポジトリにコミットします。
11. リリースをリポジトリ内のタグにコピーします。例えば。/ project / tags / rel-123 /
12. Phingを使用してステージングサーバーにアップロードします。（誰かが「テスト」以外にステージングサーバーが何に使用されているかを正確に明確にしていただけませんか？）
13. Phingを使用して、ライブサイトを更新する準備をしたり、DB/デプロイを設定したりします。

私は最近、デバッグについて読むことに多くの時間を費やしました。継続的に参照された側面の 1 つは、単なるバグ追跡システムではなく、バグ解決プロセスでした。私は、人々が問題のテイクを書き留めていること（それが機能したか機能しなかったか）、修正の特定のテイクが機能するかどうかを判断するテストなどについて読みました。

だから私は「ねえ、これはいいアイデアだ」と思っています。

私は現在Mantisを使用していますが、その機能を持っていないようです（フィールドを悪用することなく）。Mantis はバグ ロガーとして最適です。でも、もっと洗練されたインターフェイスを探していると思います。

例

私のバグが「ズボンが落ちる」だったとします。次に、この情報を次のようにログに記録したい...

「ズボンが脱げる 2009年2月32日 25時61分 部屋に入ったらズボンが脱げた！」

開発者 1...

仮説1：パンツが大きすぎる。

テスト1：ベルトを装着。

考えられる解決策 1: ベルトを購入する。

結果=?? 結果 ？？？

テスト 2: 子供の妹のズボンをはきます。

考えられる解決策 2: 彼女の部屋に忍び込み、学校にいる間に彼女のズボンをすべて持っていきます!

結果 = ??、日付/時刻 = ???

開発者 2...

仮説 2: あなたのズボンには穴が開いています。

テスト 1: それらに光を当てます。

考えられる解決策: 新しいパンツを購入する。

結果 = ???、日付/時刻 = ???

さて、これはばかげた例です。しかし、ソフトウェアツールとしては素晴らしいと思います。そのようなものは存在しますか?存在する場合、それは何と呼ばれますか?

私はシニアソフトウェアエンジニアであり、数か月前にバグ修正の調整を手伝うように頼まれました。プロジェクトマネージャー（非技術者）は、生産性を1人/日あたり1つのバグ修正に改善するという目標を私に与えました。これは本当に難しいことであり、バグ修正率を向上させるために他の開発者/管理者が何をしたのか知りたいです。

この状況で役割を果たすいくつかの要因：

• チームは地理的に分散しており（ヨーロッパ、アジア、オーストラリア）、各地域に10〜20人の開発者がいます
• 会社に9か月しかいないので、あまり馴染みのない大規模なコードベース
• 経験の浅い開発者のみがバグ修正に割り当てられ、最も有能な開発者は機能拡張に取り組んでいます
• 私たちはアジャイルに従うので、ソース管理、継続的インテグレーション、バグデータベースを使用し、プロジェクトには新しい作業のスケジュールと仕様があり、テスターがいて、ユーザビリティテストを行います
• 私たちのコードは、社内およびサードパーティのコンポーネント/ライブラリの多くに依存しています
• プログラムマネージャーにはいくつかの古いバグ修正メトリックがあり、1人/日あたり0.7のバグ修正を示しています。私の懸念は、これがプロトタイプに取り組んでいる経験豊富な開発者のチームに基づいており、彼ら自身が書いたコードのバグを修正していることです。現在、コードに精通していない開発者のチームを調整しています。バグは検証チームに起因しています。

最初のいくつかの回答を読んだ後のいくつかの詳細：

• 私はバグ修正された生産性メトリックを使用することに反対しようとしましたが、このアプローチでは行き過ぎではありませんでした
• すべてのバグに優先順位が付けられ（1-5）、重大度（1-5）が含まれ、追加情報でタグ付けされます（たとえば、別のバグによってブロックされた、クラッシュ、再現不可能など）
• ほとんどのバグには、修正時に単体テストケースが記述されています
• コードの特定の領域のバグは、可能であれば、その領域に精通している人々に割り当てられます
• バグ修正率はチームごとに追跡され、修正履歴が保持されます
• 毎日のスタンドアップでは、ブロックの問題を求めて解決することで、人々を動かそうとしています。
• すべての新しいコードは単体テストで書かれています
• はい、私はさまざまな方法で生産性メトリックを改善するために最善を尽くしています-古い無関係なバグを閉じ、バグレポートなしで解決される問題のバグを作成して修正します

• バグデータベースに直接アクセスして、バグ管理のありふれた側面を自動化し、レポートを作成するPythonスクリプトを開発しました。

-

プロジェクトで使用するバグ/問題追跡システムを選択しています。 この質問とこの質問は、評価するシステムを提供するのに役立ちます。しかし、提供されているさまざまな製品を調べて質問があります。

一部のシステムは、機能としてソースコード管理システムの統合を促進します。これは私が以前に使用したものではなく、さまざまなツールのWebサイトを見ると、この統合が提供するものの詳細を正確に見つけることができません。バグを発生させるために使用するのと同じWebインターフェイスを介してリポジトリを参照するだけですか？

では、そのような統合にはどのようなメリットがありますか？どのように時間を節約したり、製品を改善したりできますか？