現在のプロジェクトでは、IIS アプリの構築と展開に Teamcity と Octopus を使用しています。
4つの環境があります。CI 環境 (チェックイン時の自動ビルド、ユニット テストの実行、自動 QA テスト)、および QA、UAT、および Prod 環境 (Octopus を使用して手動でプッシュ)。
ローカル (開発) ビルドでは、デフォルトのビルド スクリプトは、テスト目的でローカルの Octopus インスタンスに直接プッシュします。
CI ビルド (非常に頻繁に実行される) をローカル ビルドと同様のモデルに従う (そして、マスター経由ではなく、Tentacle インスタンスに直接プッシュする) か、Octopus サーバーを経由する (必要なビルドが行われるたびに新しいリリースが作成されます)。
あなたの質問は関連しているように見えますが、そうではないと思うので、この回答を2つに分けます.
パート1
パッケージのサイズと各ビルド (自動ユニット/qa テストを含む) の時間に応じて、次の 2 つのオプションがあります。
少なくとも、CI および QA 環境にデプロイすることをお勧めします。テスターが最新の展開をテストすることだけが理にかなっています。
パッケージ サイズについて言及する理由は、1 日に 15 ～ 20 のビルドを実行し、すべての単体テストで 50 MB 以上のパッケージを生成する場合、注意しないとビルドがキューに入ってしまう可能性があるためです。適時性が要因です。各チェックインのビルド、nuget パック、プッシュ、およびデプロイに 20 分かかる場合は、問題ない可能性があります。しかし、1 日 20 分 x N 回のチェックインがあると、日中までにビルドをキューに入れる可能性があります。言うまでもなく、ストレージが（ゆっくりと）問題（またはストレージ不足）になる可能性があります。私はあなたのプロジェクトの詳細をすべて知っているわけではありませんが、これらの要因を念頭に置いておいてください.
何をしたい場合でも、Octo.exe を使用する必要があります。#1 (継続的デプロイ) を実行する場合は、単純な Powershell スクリプトを記述して、ビルド手順の後に Octo.exe コマンドを実行し、パッケージを選択した nuget サーバーにプッシュすることができます。コマンドについては、Octopus に最新のパッケージを取得するように指示するだけです。
夜間ビルド オプションを実行する場合は、TeamCity を変更して別のスクリプトを実行する代わりに、Windows サーバーで特定の時間にそのスクリプトを実行するタスクをスケジュールすることを除いて、同じことを (スクリプト単位で) 実行します。 . これは最も賢明なオプションですが、これから継続的な展開オプションに切り替えることは難しくありません。
パート2
パッケージをサーバーから直接フェッチするか、NuGet サーバーから直接フェッチするかは問題ではありません。どちらかを選択する際のガイドとなるいくつかのことを念頭に置いてください。
パッケージのサイズを考慮してください。パッケージが大きいほど、Octopus IO の負荷を考慮して、nuget サーバーに直接アクセスすることが望ましいと思います。おそらく、これは大したことではないでしょう。
環境ごとのサーバー数 - 特に各環境に複数のサーバーがある場合。デフォルトでは、Octopus は並列展開を試みますが、「ローリング」展開に切り替えることができます (一度に展開する特定の数のサーバーを設定します)。チェックインごとに継続的な展開を行っている場合、各触手は最新のパッケージをダウンロードする必要があります。繰り返しになりますが、パッケージのサイズとプッシュする触手の数によっては、帯域幅の問題が発生する場合があります。繰り返しますが、あなたの環境にいくつのサーバーがあるかわからないので、何が最善かを本当に知っています.
Octopus サーバーを使用している他のチームはありますか? 私が尋ねるのは、あなたが唯一のチームであれば、各触手がどのようにパッケージを取得するかを本当に心配する必要がないからです. nuget サーバーから直接送信するか、Octopus サーバーから送信するかは問題ではありません。
Octo.exe ドキュメントへの URL は次のとおりです: http://docs.octopusdeploy.com/pages/viewpage.action?pageId=360596これは、ビルドを必要な環境に完全に自動化するための親友です。
何を選択しても、デプロイを自動化することを強くお勧めします。限目。自動化した後、なぜわざわざ手動でデプロイしたのか不思議に思うでしょう。octo.exe はoctopus サーバー自体で実行する必要はありません。
Octo.exe は Octopus API を使用し、この API とすべての通信を行います。したがって、Octopus サーバーにアクセスできる任意のマシンから Octo.exe コマンドをテストできます。デスクトップで試してみて、うまくできたら、スクリプトに入れてテストすることをお勧めします。
したがって、「いつ」リリースを作成する必要があるかという OP のポイントを明確にするために、それは非常に主観的であり、Octopus 内のプロジェクトは 1 つ以上の NuGet パッケージをデプロイできるため、ケースバイケースで異なります。とは言うものの、リリースのバージョン管理について何らかの承認が必要であり、必然的にバイナリと Nuget パッケージのバージョン管理もアリーナに持ち込む必要があると思います。
例: テスターが TFS 変更セット番号に大きく依存している場合は、その変更セット番号を (AssemblyVersionInfo を介して) バイナリに埋め込み、NuGet パッケージにそのバージョンを (NuSpec で) 反映させてから、リリースに NuGet パッケージのバージョン管理を Octopus に使用させるのが最善です。 . 甘い。リリース バージョンは変更セット番号を表示できます。素晴らしい。ただし、プロジェクトが複数の NuGet パッケージをデプロイしている場合は除きます。では、展開全体のバージョンとして機能するパッケージはどれでしょうか? プロジェクトとデプロイ プロセスごとに複数の NuGet パッケージがある場合、状況は非常に複雑になります。そのため、通常、Octopus の他のバージョン管理メカニズム (別名変数テンプレート) が誰にとっても最適に機能します。
特にベスト プラクティスに取り組む場合は、Octopus 内のプロモーションの背後にある概念も重要な機能であることを覚えておいてください。展開プロセス、NuGet パッケージのバージョン、および変数値の一貫性だけでなく、バージョン番号 (NuGet または変数テンプレート) が環境全体で一貫しているため、環境間でリリースを昇格することをお勧めします。1.0.1、1.0.2、1.0 のように新しいリリースを作成するよりも、すべての環境でリリース 1.0.2 を確認し、1.0.2 が完全にテストされていることを視覚的に確認する方がはるかに簡単です。 .3、1.0.4 など、特にコードがまったく同じ場合。プロモーションを使用すると、NuGet パッケージ バージョンがすべて同じである別の環境にリリースを (効果的に) 再デプロイできます。変数の設定と展開プロセス - すべて同じリリース バージョン内。恥知らずなセルフプラグとして、ここにこのバージョン管理の問題に関する私のブログ投稿。
リリースを作成する「時期」に関するベスト プラクティスはありますか? コードを変更するには、新しいリリースが必要です。同じコードを別の環境に移動するために新しいリリースを作成する必要はありません。ただし、リリースに関心がある場合は、バージョン管理にも関心を持つ必要があります。
要約すると (TL;DR):
現時点で頭の中で思いつくのはこれだけです。これが物事を明確にすることを願っています。