問題タブ [fogbugz]

Fogbugz XML API に接続する Android アプリケーションを作成しています (API にリクエストを送信し、XML ファイルを受信します)。現在、これらのリクエストを処理し、使用可能な情報にアクセスするためにそれぞれを解析するサービスを作成しています。これを行う最良の方法は何ですか？inputStream を取得している場合、SAX パーサーを使用する必要がありますか?

TFS から Fogbugz Kiln に移行すると、どのような問題が発生する可能性がありますか?

現在、ソース管理に TFS を使用していますが、Kiln に移行するオプションを検討しています。

Visual Studio .net、SQL サーバー、TFS、Windows サーバーなどを使用しているため、完全に Microsoft 開発ツール ベースの会社です。

移動の理由は次のとおりです。

1. kiln のより良いコード レビュー ツール
2. より良いブランチ マージ管理。

誰かがすでにこれを行っていますか？キルンでビジュアルスタジオを使用するときの問題を知っている人はいますか?

FogBugz を IssueTracker として TeamCity に接続できますか? 現在、接続用に 3 つのドライバーのみを確認できます: Bugzilla、Jira、および YouTrack。ありがとう

ハウディ。私は新しいソフトウェアチームを編成し、他のチームで抱えていた以前の悪夢を克服するさまざまなツールを検討しています。

過去5〜6年間で、これらは私が行ったいくつかの移行です。

SourceControl：
CVS => VSS => SVN

プロジェクト管理、バグおよび問題追跡：
紙=>付箋=> OneNote => BugNet => OnTime

Wikiとドキュメント：
Word+ネットワーク共有=>ScrewTurn Wiki

Builderの自動化：
Cruise Control + MSBuild

現在、特にSVNとWikiの状況のた​​めに、私はこのチームを何か新鮮なものから始めることを検討しています。過去に、SVNで悪夢を分岐させてきましたが、修正しようとすればするほど、最悪の事態になります。私が抱えているもう1つの課題は、安定して統合されたものを見つけることです。BugNet + SVN + ScrewTurn + CruiseControl + MSBuildはまったく異なる動物であるため、統合と相乗効果が非常に重要であることが想像できます。バグを報告したり、タスクを割り当てたり、完了した作業を確認したり、リポジトリログを確認したりするために、10の異なるアプリケーション間を行き来したくありません。
それで、新しいチームと私はこれについて数日間話し合っており、2つの可能性に絞り込んだと思います。1。TFS

2010の
長所：
-オールインワンソリューション。新しいSCRUMプロセステンプレートを含め、すべてが揃っています。
-非常に使いやすいユーザーインターフェイスとSharePointの統合。
-WYSIWYGWikiとOfficeの統合。
短所：
-ハードウェアと管理時間の初期費用が高い。ソフトウェアもありますが、無料のソフトウェアを使用したMSDNサブスクリプションがあるため、影響はありません。
-TFSのソース管理については躊躇しています。SCはファイルベースであり、SVNやVSSと同じように中央リポジトリを備えています。私は本当に過去に私たちが持っていたのと同じ問題に陥りたくありません。

2. FugBUgs + Kiln + CCの
長所：
-Kiln はMercurialを使用しており、分散ソース管理のすべての利点があります。
-最小限の初期費用と、稼働させるための計画時間。ユーザーあたり月額$30.00。
-非常にフレンドリーなWebユーザーインターフェイス。
-WYSIWYGWikiエディター。
-非常にシンプルな課題追跡ツールとプロジェクト管理ツール。SCRUMプロセスを統合するのは簡単です。
短所：
-より統合されたプロセス（TFSなど）用のビルダー自動化ツールが不足しています。したがって、これは、ビルダーワーカーを維持するために、コマンドライン機能とコミュニティタスクで頭を悩ませ続ける必要があることを意味します。

当時、私はVisual Studio Team System 2005を使用していましたが、システムについて最高の思い出を持ちませんでした。しかし、新しいTFS2010は非常に堅実な賭けのようです。FogBugzとMercurialは、ブロック内の新しい子供たちのようなもので、新しいプロセスに新鮮な思考をもたらしますが、いつものように、これは両刃の剣です。
これらのいずれかで確かな経験を持っている人はいますか？その3番目のオプションがありませんか？私の問題に対するその銀の弾丸はありますか？

1. ツール統合
   1.1。ソース管理
   1.2。Wiki1.3
   。ビルド自動化
   1.4。プロジェクト管理
   1.5。課題追跡システム
2. ソース管理の分岐とマージの競合を最小限に抑えます（はい、分岐してマージする必要があります）
3. フレンドリーなユーザーインターフェイス（誰もがCMDハッカーというわけではありません）
4. WYSIWYGWiki。
5. 開発者のための学習曲線。
6. すべてをVSで実行する時間です。長期的な価値。

新しいチームには、4人のチームメンバー+ 1人のプロジェクトマネージャー（スクラムマスター）と1人のプロダクトマネージャー（プロダクトオーナー）がいます。つまり、比較的小規模で新しいチームについて話しているのです。私たちが取り組む範囲とプロジェクトは、複数のプロジェクトと分岐のバリエーションを持つ大規模なエンタープライズアプリケーションです

FogBugz が「現在の作業画面のスクリーンショットを撮る」機能をどのように実装したか知っている人はいますか? これは純粋にphp経由で行われますか? パール？フラッシュスクリプト？

FogBugz はどの wiki エンジンを使用していますか?

Fogbugz には、キーボード ショートカットの非常に優れた実装があります。

CTRL+を押す;と、次に押すキーは、現在のページのユーザー インターフェイス要素に対応します。

これにより、既存のブラウザーのキーボード ショートカットとの競合がうまく回避されます (単純にCTRL+ A、CTRL+ B.. スタイルのショートカットを追加しようとした場合など)。

CTRL+ ;「各アクションの上に小さな黄色いタグがショートカットとともに表示されます。」そのため、いつでもすぐにキーボード ショートカットを参照できます。

詳細はこちら: http://fogbugz.stackexchange.com/questions/4310

私たちが使用できる jQuery ベースの (または他の) 実装を見た人はいますか?

このチュートリアルIntegration SVNを読み、プロジェクトの BugzID をセットアップしました。

現在、別の問題があります。私のプロジェクトは開発中で、新しいファイルまたはモジュールが追加される可能性があります。BugzID を新しいファイルまたはモジュールに自動的に追加するにはどうすればよいですか? ありがとう。

ローカルでコミットされたとき、またはキルンリポジトリにプッシュされたときに、チェンジセットに自動的にタグを付ける方法があるかどうかを知りたいです。

すべてのチェンジセットにバージョン/ビルド番号のタグを付けてほしい。バージョン/ビルド番号をデータベースに保存することを計画しており、スクリプトでデータベースからこの値を取得し、変更セットにタグを追加したいと考えています。スクリプトを自動的に呼び出して、これをコミット後のイベントとして、またはキルンリポジトリにプッシュされたときにプッシュ後のイベントとして実行することは可能ですか？

また、すべてのコミット/プッシュで自動タグ付けを実現するための他のアプローチも受け入れています。

問題の追跡にFogbugzを使用しており、FogbugzのXMLAPIの周りにC++ラッパーを作成している最中です。

ベストプラクティスは、「スカウト」フィールドを使用して、類似/同じクラッシュがカウントされるだけで、再度報告されないようにすることです。そのためには、クラッシュの特定の原因に対する一意の文字列が必要です。

Win32の場合-dmpファイルまたは他のクラッシュハンドラーを取得した後、クラッシュの一意の文字列を作成するための良い方法は何ですか？（dmpファイルを作成してfogbugzサーバーに送信します）

以前の投稿/記事などで、Joelはさまざまな提案をしましたが、それらの多くは、リフレクションを使用し、取得が難しいか取得できない多くの情報を持っているC＃のような言語に頼っています。

他の人は、スタックトレースや、fogbugzにスカウトエントリを作成するための他のものなどを入手しましたか？

編集明確にするために-すべてのインシデントに一意のIDは必要ありません-同じコードパスを持つクラッシュが発生する可能性があります。それを捉えたい。コードに含まれる最後の数個のスタック呼び出し（win32 DLLからの呼び出しではない）を取得することを考えていましたが、これを実行する方法がわかりません。

すべてのクラッシュを一意として報告するのは正しくありません。同じケースですべてのクラッシュを報告するのは正しくありません。クラッシュの原因となるシナリオを繰り返すさまざまなユーザーは、同じインシデントにマッピングする必要があります。

編集

私たちが望んでいるのは、スタックにあるものに基づいた、クラッシュの一般的な「シグネチャ」です。同様のスタックは同じ署名を持つ必要があります。たとえば、アプリにある上位5つのメソッドを取得してから、最初の呼び出し（存在する場合）をMSDLLにします。これはおそらく署名には十分であり、「同じ」クラッシュを相関させる可能性があります。

では、スタック上のメソッドのリストをどのように取得するのでしょうか。そして、それらが自分のアプリからのものか、別のDLLからのものかをどのように判断できますか？

編集-注ミニダンプを作成し、スカウトの説明としてfogbugzに送信できるように、例外ハンドラーで「バケットID」/署名を作成します。または、アプリの次の起動時にダンプをロードし、生成した署名を付けて送信することもできます。