問題タブ [ms-release-management]

Microsoft Release Management for Visual Studio または "InRelease" として知られているアプリケーションを展開しようとしています。しかし、MSI-Deployer を使用すると予期しない問題に直面します。

次のフロー エラーでデプロイが失敗します。

最初の提案（間違ったパス）は当てはまりません。私はそれを再確認しました。では、Deployer ユーザーがサーバーにアクセスできないのはなぜですか? そして、それを修正する方法は？

ローカル サービスとしてドロップ フォルダーに XXX139W8$ アクセス許可を追加し、ドロップ フォルダーの管理者権限を持つドメイン ユーザーとして実行して、DeploymentAgent を管理者として実行してみました。

残念ながら、展開エージェントに完全に到達できないか、上記のエラーが表示されます。システム仕様の一部を次に示します。

TFS および RM Server は、SQL Server Express 2012 がインストールされた Windows Server 2012 R2 上で実行されます。私が取り組んでいるクライアントは、Microsoft Visual Studio 2013 の Release Management Client を使用しています。ターゲット マシンは Windows 8.1 です。

さまざまな開発サーバーへのソリューションの展開を自動化するために、Microsoft のリリース管理ツールを使用しています。このツールは、複数のサーバーにまたがるより複雑な展開を実行できるため、私たちにとって理想的です。この意味で、正常に機能しており、すべてが正しく展開されています。

マイナーな問題は、Release Management がビルドを自動的にデプロイした後、ロック アイコンで示される「無期限に保持」にビルドを設定することです。継続的な展開を行っているため、多数のビルドを保持しており、ビルド定義の保持ポリシーはオーバーライドされています。したがって、定期的にアクセスして、以前のビルドをすべて強調表示し、[無期限に保持] の選択を解除する必要があります。

Release Management を使用して過去の開発を展開していないため (残念ながら許可されていません)、これらの開発ビルドをすべて保持する必要はありません。

ビルドを無期限に保持するように設定しないようにリリース管理を変更する方法はありますか?

更新:これは現在不可能であるため、この機能が必要な場合は、UserVoice で投票してください: https://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/6537614-allow-retain-indefinitely -設定しない

ビルドからリリースをトリガーしようとすると、上記のエラーが発生します。ビルドは単独で動作し、リリースも単独で動作しますが、リリースをトリガーできません。

私の問題は、リリース管理にシステム ユーザーのようなものが存在しないことです。サービス利用者が存在し、上記利用者をサービス利用者とする。リリース マネージャーとしても設定されます。

これは、TFS のプロジェクト コレクション管理者グループにもあり、「他のユーザーに代わって要求を行う」アクセス許可を持っています。これを機能させるために必要だと思うことはすべて実行しました。

私が考えることができる唯一のことは、Release Management が TFS とは別のサーバーにインストールされており (ビルド エージェントと同じサーバー上にありますが)、おそらく "別の" NETWORK SERVICE ユーザーを使用していることです。 NETWORK SERVICE ユーザーはローカルです (よくわかりませんが)。

私は見つけることができるすべてを試しました。他の人がこのエラーを受け取っていますが、Release Management で Service User 権限を設定することで常に解決されるようです。

これを機能させるために設定する必要があるものは他にありますか?

ありがとう。

現在、Visual Studio リリース管理ツールを使用して、コードのリリース フェーズを管理しています。現時点では、各ターゲット マシンに専用の展開エージェントをインストールする必要があるアクション ベースの古いテンプレートを使用しています。将来的には、Desired State Configuration アプローチを使用する予定ですが、今の自分では答えられない問題に遭遇しました。これは DSC パイプラインにも当てはまると思いますが、現在はアクション/コンポーネント ベースのパイプラインに焦点を当てています。

RM では、マシン スコープにのみアクションとコンポーネントを配置できます。パイプラインで選択可能な展開エージェントがインストールされたサーバーがあり、それらはワークフローの基本エンティティです。すべてがこれらのマシン スコープ内に入ります。

しかし、それ自体はインストールではないリリース要件があります。自動化したいアクションの 1 つは、Google Play での Android APK の公開ですが、何もインストールしないため、これは特定のマシンに依存しません。ドロップ フォルダーにある apk 自体が必要ですが、それをマシンにコピーする必要はありません。

RM ではマシンのスコープ外にアクションやコンポーネントを配置することはできないため、ツール内でマシンに依存しないリリース アクションを実行するには、どのような戦略が必要ですか? 展開エージェントを RM サーバーと同じマシンにインストールし、別のマシン スコープ "localhost" を使用してこれを行うことを考えましたが、非常に複雑なようです。

私が望んでいたのは、TFS ビルドの仕組みと非常によく似ています。ビルド ワークフローが開始されると、ビルド コントローラーで実行され、そのスコープに任意のアクティビティを配置できます。次に、ワークフローのある時点で、ビルド エージェントでタスクの実行を開始します。RMの「コントローラー自体で実行」に似たものはありますか?