ピアレビューを奨励するために、チームサービスのリリース定義にソース管理を使用するにはどうすればよいですか？

私は他の人にリリース定義を変更するよう委任しています。変更が保存される前にその変更内容を確認したいと思っています。ピアレビューを奨励するために、チームサービスのリリース定義にソース管理を使用するにはどうすればよいですか？

ソースコントロール（GitまたはTFVC）を使用して、ライブになる前にこれらの変更を確認できます。

uservoiceにリクエストを追加する前に、これについての推奨方法がありますか？私のgoogle-fooは答えにならないのですか？

リリースとビルドの定義は、選択したリポジトリではなく、クラウドに保存されているようにしか見えないことが常にわかっています。私たちはjsonファイルを見て、ブラウザで保存した後で比較することができます。ビルドやリリースが保存されたときにコメントフィールドに作業項目の参照を作成する以外に、Who, how and why did the build/release definition get to look like this?の履歴を提供するために、それらをワークアイテムにリンクすることはできません。以前は、古いTFSBuild.projまたは新しいXAMLビルドファイルは、少なくともソース管理の対象でした。

Microsoftの誰もがこれに関するいくつかの洞察を持っていますか？私たちはそれを間違って使用していますか？

おかげ

出典

2017-02-01 Rick Glos

がバージョンを保存し、異なるブランチで作業することができるようにするために行われているあなたのようなツールを探しているように、聞こえる// WWW .reviewboard.org/ – alfasin

彼らは「コードとして定義を構築し、解放」のためのサポートを追加するために、私は大好きですが、あなたはREST APIを使用してプロセスをごまかすことができます。

リリース定義をソース管理にJSONとして格納し、コミット時にTFS REST APIを使用してリリース定義を更新/インポートするCIプロセスを作成します。既存のリリース定義をJSONとしてエクスポートしてベースラインを提供することができます。これを処理するための市場には多くの拡張機能があります。また、REST API経由でエクスポートすることもできます。この時点で、リリース定義を直接変更してサービスアカウントへのアクセス権を制限することができないようにすることができます。

リリース定義のGUIに対して作業したい人は（それは妥当です）、リリース定義を作成/変更する権限を持つサンドボックスチームプロジェクトにアクセスできるようにすることができます。彼らは調整が終わったらいつでもそれをエクスポートすることができます。

出典

2017-02-01 20:54:52

私はREST APIを見て、これらの見せかけの線に沿って考えていましたが、このようなサイドクエストで時間を無駄にしないことを望んでいました。 Welp、ここでは、すぐに使えるものがあることを期待しています。 –

リリース定義の変更を確認する機能はありません。ダニエルが提供した回避策は良いです。

私はここで、ユーザの声を提出します。https：ソースコントロールを使用してReview changes of release definition

出典

2017-02-14 03:24:19

ピアレビューを奨励するために、チームサービスのリリース定義にソース管理を使用するにはどうすればよいですか？

答えて

関連する問題