3

私は本 Pro Nuget を読み終えました。現在の方法よりも依存関係に利用する方が良いと思います。また、アプリケーション展開パッケージをビルドして、さまざまな環境にビルドを展開することもできます。これも自動化の改善を目指しています。

アイデアの 1 つは、複数の Nuget フィードを用意することです。統合が成功するたびにパッケージが公開される ci フィード、qa にテストしてもらいたいバージョンのみを公開する qa フィード、テストに成功した qa フィードからパッケージのみをコピーするリリース フィードです。

私はこのアイデアを気に入っていますが、バージョンを -alphaXXXX などで終了することにより、ci ビルドをプレリリースとしてマークすることをお勧めします。ただし、それを行う場合は、qa フィードへのプロモーション中にその指定を削除する必要があります。そのためにはパッケージを変更する必要があると思いますが、Nuget パッケージの魅力の一部は、一度ビルドすると変更しないことです。

もう 1 つのアイデアは、私たちは主にトランクで作業しているため、rc ブランチを作成すると、ビルド プロセスがバージョンのプレリリース部分の追加を停止するというものです。それは機能するようで、qa からリリース フィードへの昇格は単純なパッケージ コピーになります。

誰かがこのアプローチを行っていますか?それは推奨されるアプローチですか? 何か不足していますか？私はグーグルで検索しましたが、そのようなアプローチの詳細について多くの議論が見つかりました。

4

1 に答える 1

3

私はこの本の著者の一人ですので、気に入っていただければ幸いです。多くの新しいコンテンツを含む第 2 版に取り組んでおり、この特定のケースにも取り組んでいます。

明確にするために、CI --> QA --> PROD シナリオは、パッケージ プロモーション フローの例として設定されています。必要に応じて、独自のシナリオを作成できます。

あなたの指摘は正しいです。パッケージのプロモーションでは、パッケージやその内容を変更する必要はありません。これは事実上、パッケージを別のフィードに昇格させるときに、パッケージ内のバイナリの再構築さえ行われないことを意味します。このルールの唯一の例外は、調整または削除できるパッケージのプレリリース バージョンです。注: セマンティック バージョンは昇格時に同じままにする必要があります。

これはhttp://www.MyGet.orgのコア機能です: これに関するドキュメントはhttp://docs.myget.org/docs/reference/package-sourcesです(シナリオ: パッケージを上流にプッシュします)。

上記の原則がこの機能に適用され、フィードのセキュリティ/API キーも処理されます。MyGet を使用しない場合は、自分でこれを行う必要があります。論理的な手順は次のとおりです。

  1. ソース フィードからパッケージをダウンロードする
  2. 必要に応じて、プレリリース タグを変更します (手動で?)
  3. パッケージをターゲット フィードにプッシュする

多くのオープン ソース プロジェクトがこのシナリオを使用しており、MyGet.org の CI フィードを使用してから、アップストリームを NuGet.org にプッシュしています。アップストリーム パッケージ ソースは、他の NuGet フィード (Chocolatey.org ギャラリー、Resharper プラグイン ギャラリー、別の MyGet.org フィードなど) にすることができます。

于 2013-07-18T23:31:15.463 に答える