3

現在、私たちのプロジェクトは、複数の製品で共有されているプロジェクトへのプロジェクト参照を使用しています。パッケージ管理にNugetの使用を開始します。典型的な開発ワークフローのベスト プラクティスについて疑問に思っています。そのうちの 1 つは、共有コードのバグ修正です。

バグ修正の現在のワークフローは非常に単純です。デバッガーを使用してバグの根本原因を特定し (共有コードにブレークポイントを設定し、共有メソッドにデバッグするなど)、共有コードに必要な変更を加えてバグを修正し、ソリューションを再構築し、検証します。すべてのバグが修正されたことを確認し、ソース管理で変更をチェックインします。

  1. Nuget を使い始めると、このワークフローはどのように変わりますか?
  2. 共有コードをデバッグできるようにするには、シンボル ソースを設定してデバッグ シンボルを発行する必要がありますか?
  3. 検証部分はどのように変更されますか？
  4. チェックインする前に、検証のためにバグ修正の可能性がある新しくビルドされた共有バイナリを手動で「packages」フォルダにコピーする必要がありますか?
4

1 に答える 1

1

  1. 以下の回答のように変更されます。

  2. はい。このビルトインを含む製品 ProGet を使用するか、NuPeekを使用して独自のサーバーをセットアップすることができます。これを Visual Studio で設定するためのガイドを作成しました: http://inedo.com/support/kb/1036/using-progets-symbol-server

  3. この部分は、特に自動化されたビルド/リリース プロセスがない場合は、少し面倒です。これらのプレリリース パッケージを格納するには、少なくとも 1 つのプライベート リポジトリが必要です。理想的には、コードを共有せずにライブラリを独自のプロジェクトに分離するため、コードを CI システムにチェックインし、パッケージをプライベート リポジトリに自動的に公開してから、リポジトリから最新の NuGet パッケージをプルする必要がある場合があります。バグ修正を検証するプロジェクトに追加します。検証が完了したら、プレリリースではなくなった別のバージョンを作成するか、パッケージをプライマリの「リリース」フィードにプッシュできます。

  4. これがうまくいくなら、なぜできなかったのかわかりません。ただし、自動化を行うと、最初にチェックインし、ビルド/リリース ツールにすべてを処理させてから、パッケージのコンシューマーと同じように NuGet クライアントで更新する方が実際には簡単です。この方法では、packages.config も更新されます。ファイルを適切なバージョンにします。

于 2013-05-23T21:52:07.880 に答える