2

3 つの異なるプロジェクト (.NET) を開発している 3 つのチームがあり、共通のコードとコントロールの SharedLibrary を持つプロジェクトが 1 つあります。各チームは、Mercurial のサブリポジトリを使用して参照します。各チームは、変更を SharedLibrary にプッシュして、プロジェクトのバグを修正することができます。そのため、1 つのプロジェクトでバグを修正すると、2 つ目のプロジェクトにバグが発生する可能性があります。

問題の追跡には JIRA を使用しており、4 つのプロジェクトがあります (各チーム用と SharedLibrary 用)。

それで、誰かが統合の失敗の可能性を減らし（あるチームが他のチームプロジェクトを壊す）、失敗が起こった場合にそれをできるだけ早く明らかにするのに役立つワークフローを提案できますか?

考慮すべき点:

  1. JIRA で SharedLibrary のバージョンが必要ですか? それはどのように維持されるべきですか？

  2. SharedLibrary に加えられた変更を検証するのはいつ、誰ですか?

  3. hg でブランチを整理する最良の方法は何ですか?

  4. JIRA ワークフローを整理する最良の方法は何ですか? JIRA のどのプロジェクトで ShareLibrary の問題がファイルされますか?

同様の状況に対するワークフロー/ソリューションのヘルプまたは例は、非常に高く評価されています。

4

1 に答える 1

0

いくつかの提案:

  1. はい、他のプロジェクトと同じように、SharedLibrary のバージョンを維持する必要があります。3 つのプロジェクトのそれぞれのリリースを、SharedLibrary の特定のバージョンに関連付ける必要があります。他のチームに言及せずに 3 つのプロジェクト チームのいずれかに変更を任せると、互換性のない変更が導入されるリスクが高くなります。
  2. SharedLibrary が特定の人またはチームによって管理されていない場合は、SharedLibrary の更新のレビューを担当する各プロジェクト チームの代表者で構成された機能横断的なチームを作成することをお勧めします。JIRA を使用して、バージョンごとに課題を追跡できます。変更が他のプロジェクトに影響を与えないことを確認するには、Jenkins などの継続的統合サーバーで実行できるプロジェクトごとに包括的なテスト セットを用意します。
  3. ここでは特に提案はありません。
  4. SharedLibrary を別の JIRA プロジェクトとして保持します。
于 2012-06-22T16:57:38.760 に答える