問題タブ [jira]

JIRA のポスト関数から集計フィールドの値を更新するにはどうすればよいですか?

VM で Jira を実行して成功または失敗した人はいますか?

新しいソース管理および欠陥追跡サーバーをセットアップしています。私のサーバー ルームはほぼ満杯で、私のサービス グループは VM を提案しました。多くの人が VM 上で SVN を実行しているのを見ました (NCSA を含む)。また、VM によってハードウェアの問題から解放され、高可用性が得られます。最後に、お役所仕事から解放され、より迅速に実装できます。

では、Jira を VM に配置してはいけない理由を知っている人はいますか?

ありがとう

フロントエンドを使用する代わりに、jira データベースから大量の課題を削除できた人はいますか? bulktools を使用して 60000 件の問題を削除することは現実的ではありません。

前回試したとき、jira は独自の方法でインデックスを作成したためにおかしくなりました。

私は JIRA の標準版を使用していますが、全体的に気に入っています。ただし、誰が問題を解決したか、現在の担当者は誰か、誰が問題を報告したかを JIRA が記録していないように見えることは、よくあるイライラの原因です。

「リゾルバー」が記録されていないため、私が解決した問題や、私が解決しなかった問題 (テストする問題を探す場合など) を見つける方法はありません。

リゾルバー追跡を「オン」にする構成オプションはどこかにありますか?

乾杯、ドン

カスタムフィールドにリビジョン固定を追加していますか?

そして、 have のポイントは何Work Startですか? 私resolve issueは十分だと思いましたか？

現在、JIRA インスタンスを共有する複数のプロジェクトがあります。ユーザーがテストを行っているプロジェクトのみを表示するようにしたいと考えています。

ただし、現在、これらのユーザーを標準のグループ化 jir​​a-users にグループ化しています。

特定のユーザーのみが表示およびアクセスできる JIRA プロジェクトを除外する最良の方法は何ですか?

私は JIRA インストールに対して動作するカスタム ツールをいくつか作成しています。公開されている SOAP API は、引数に名前がないことを除けば素晴らしいものです。

たとえば、getIssue のプロトタイプは次のとおりです。

すべての SOAP RPC メソッドはこの規則に従っているため、ドキュメントがないと、これらの多くで何を渡すかを理解するのにかなり苦労しています。

決定的な API ドキュメント ガイドを知っている人はいますか?

個別にリリースされた複数のアーティファクトに影響を与えるバグの変更やテスト作業をどのように追跡していますか?

コード共有は、コードを介したパスの総数を減らすため、優れています。つまり、より少ない変更とより少ないバグ (またはより少ない変更でより多くのバグに対処) でより多くの影響を与えることを意味します。たとえば、同じファイル処理パッケージまたはモデル パッケージを使用する検索ツールとインデクサーを構築する場合があります。

変更がすべての適切なコンポーネントでテストされ、どの変更がどのリリース済みツールに含まれていたかを追跡できるようにする必要があります。また、すべてのアプリケーションで同時に変更をリリースする必要はありません。

目標: 1 つのバグをテストし、リリースされた各アプリケーションに対して個別に追跡をスケジュールします。アーキテクチャを理解する自動化されたシステムにより、正しい選択を行うことができます。

バグ分割リリース シナリオ:

ユーティリティ ライブラリのパフォーマンス修正を含む検索ツールのパッチをリリースする場合があります。検索ツールにとって重要な修正プログラムは、インデクサーではあまり見えないため、次のメンテナンス リリースまで待つことができます。検索パッチで 1 つのバグをスケジュール、追跡、リリースし、インデクサーの次のメンテナンス リリースまで延期したいと考えています。

そのため、追跡システム (JIRA) でバグを作成すると、魔法のように複数のオブジェクトになるようにしたいと考えています。

• 問題を説明し、開発作業を追跡する主要な問題
• テスト作業を追跡し、影響を受けるアプリケーションごとにこの問題がどのようにリリースされたかを追跡できるようにする一連のタスク。

どの変更がどのリリースに影響を与えるかを知らずに、または人々に多くの重複したバグを入力させることなく、より多くのコード共有を促進するために、コード共有のユーザー エクスペリエンスを低労力で作成するにはどうすればよいでしょうか?

Eclipse から Linux ディストリビューションまでの大規模なプロジェクトは、この種の問題に直面しており、どのように解決したのか疑問に思っていることは確かです (次はそれらについて詳しく説明します)。

この種の状況を経験したことがある人はいますか?どのように対処しましたか?

私たちはバグ追跡とリリース管理に JIRA を使用し、JIRA 内のプロジェクト管理に greenhopper を使い始めましたが、ユーザー ストーリーとそれらのユーザー ストーリー内のタスクの考え方が欠けています。ユーザーのストーリーとタスクを完全にサポートし、ユーザーにとって高速でシンプルなアジャイル プロジェクト管理ツールのような他のタスク ボードを推奨する人はいますか? 私は targetprocess を調べ始めたので、特にそれについてフィードバックがあれば、それも素晴らしいでしょう。

誰かがアジャイルを行おうとしている場合、私はこれに JIRA / Greenhopper を使用する方法を見つけようとしています。私たちはグローバルな開発チームであるため、ここでは分散型の性質が非常に重要です。

当初はスクラムワークスを使用していましたが、チームは、JIRA とスクラムワークスに常に重複した情報があり、冗長であると考えていると不満を漏らしていました。

私たちは Greenhopper を手に入れ、それで問題が解決すると考えましたが、これに関して私が抱えている問題は次のとおりです。

1. JIRA にユーザー ストーリーの概念がない
2. Greenhopper も、ユーザー ストーリー レベルでの集計なしで「タスク」に焦点を当てています。

JIRA でこれを成功させた人はいますか、それともスクラムワークなどの他のツールに戻って、サポート チームが提起したバグに JIRA を使用することを検討する必要があります。