個別にリリースされた複数のアーティファクトに影響を与えるバグの変更やテスト作業をどのように追跡していますか?
コード共有は、コードを介したパスの総数を減らすため、優れています。つまり、より少ない変更とより少ないバグ (またはより少ない変更でより多くのバグに対処) でより多くの影響を与えることを意味します。たとえば、同じファイル処理パッケージまたはモデル パッケージを使用する検索ツールとインデクサーを構築する場合があります。
変更がすべての適切なコンポーネントでテストされ、どの変更がどのリリース済みツールに含まれていたかを追跡できるようにする必要があります。また、すべてのアプリケーションで同時に変更をリリースする必要はありません。
目標: 1 つのバグをテストし、リリースされた各アプリケーションに対して個別に追跡をスケジュールします。アーキテクチャを理解する自動化されたシステムにより、正しい選択を行うことができます。
バグ分割リリース シナリオ:
ユーティリティ ライブラリのパフォーマンス修正を含む検索ツールのパッチをリリースする場合があります。検索ツールにとって重要な修正プログラムは、インデクサーではあまり見えないため、次のメンテナンス リリースまで待つことができます。検索パッチで 1 つのバグをスケジュール、追跡、リリースし、インデクサーの次のメンテナンス リリースまで延期したいと考えています。
そのため、追跡システム (JIRA) でバグを作成すると、魔法のように複数のオブジェクトになるようにしたいと考えています。
- 問題を説明し、開発作業を追跡する主要な問題
- テスト作業を追跡し、影響を受けるアプリケーションごとにこの問題がどのようにリリースされたかを追跡できるようにする一連のタスク。
どの変更がどのリリースに影響を与えるかを知らずに、または人々に多くの重複したバグを入力させることなく、より多くのコード共有を促進するために、コード共有のユーザー エクスペリエンスを低労力で作成するにはどうすればよいでしょうか?
Eclipse から Linux ディストリビューションまでの大規模なプロジェクトは、この種の問題に直面しており、どのように解決したのか疑問に思っていることは確かです (次はそれらについて詳しく説明します)。
この種の状況を経験したことがある人はいますか?どのように対処しましたか?