多くの場合、プルリクエストチェックの一部として、コードレビュー自体に加えて、一連の定期的なチェックを行う必要があります。 一部のチェックはPRの設計に関係する場合があります。 その他は、変更採用プロセスの基礎を形成する関連条件をチェックすることです。
定期的なチェックが自動化されていない場合、人はそれらを忘れたり回避したりする可能性があります。 ルーチンは退屈だからです。
Visual Studio Team Servicesは、プルリクエストを処理するための非常に便利なインフラストラクチャを提供します。 これには、カスタムマージビルドポリシー、レビュアーの任命、受け入れられた変更のマージルールが含まれます。 これらはすべて、コードについて議論およびコメントするための便利なシステムによって補完されます。
プルリクエストプロセスを拡張する最も強力なツールは、外部プラグインポリシーです。
それらの作成と使用について説明します（そしてコードを参照）
拡張可能なプルリクエストステータス
PRステータスは、コンテキスト内で定義されたフラグです。 コンテキスト-コンテキストの名前と「ジャンル」の一意の組み合わせ。 このジャンルは通常、ステータスを操作するアプリケーションごとに1つです。
例：
ステータス1：ジャンル= 'my-policy'、名前= 'check-1'
ステータス2：ジャンル= 'my-policy'、名前= 'check-2'
ステータスは、事前定義された値のいずれかを取ります。 プロセスをサポートするために、成功と失敗の2つに関心があります。
ブランチポリシーの設定時にステータスを使用できます。PRを受け入れるには、選択したフラグがステータスに成功している必要があります。 同様に、ドライバーの数、添付されたチケットの存在などをチェックする組み込みポリシーが実装されます。
ブランチポリシーを編集します。 外部ポリシーを追加します。
ステータスが少なくとも1回設定されている場合は、ドロップダウンメニューで使用可能になります。
下部では、ステータスのタイトル、プルリクエスト完了ブロックでのステータスの表示方法を指定できます。
追加されたステータスは、チェックブロックのプルリクエストページに表示されます。
ステータスがポリシーとして使用されていない場合、その値は[ステータス]セクションのページに表示されます。 ステータスがポリシーとして指定されている場合、ブロックの上部に表示されます。
プログラムステータス管理
PRステータスは、REST APIを使用してプログラムで操作できます。 したがって、追加のPRチェックを実装し、その結果を変更プロセスに直接変換することができます。
新しいステータス値はCreateメソッドによって追加されます 。 結果とコンテキストに加えて、ユーザーに表示されるテキストを伝える必要があります。 オプションでURLを渡すことができます。この場合、PRフォームのステータスラベルはリンクになり、ユーザーはステータスの詳細が記載されたページにアクセスできます。
メソッド呼び出しにより、新しいPRステータスレコードが作成されます。 1つのコンテキスト内で、最後に追加されたステータス値がアクティブと見なされます。 以前のステータスエントリはUIからは表示されませんが、 Listメソッドを使用して取得できます。
前の図のステータスのステータスの場合、プルリクエストのステータスの実際のリストは次のようになります。
{ "value": [ { "id": 1, "state": "failed", "description": "PR title format", "context": "@{name=check-title; genre=my-pr-policy}", "creationDate": "2018-11-06T18:35:57.0324172Z", "updatedDate": "2018-11-06T18:35:57.0324172Z", "createdBy": "Masked value", "targetUrl": null }, { "id": 2, "state": "failed", "description": "Build for last update", "context": "@{name=check-build; genre=my-pr-policy}", "creationDate": "2018-11-06T18:35:57.5167963Z", "updatedDate": "2018-11-06T18:35:57.5167963Z", "createdBy": "Masked value", "targetUrl": null }, { "id": 3, "state": "succeeded", "description": "No offset from develop", "context": "@{name=check-offset; genre=my-pr-policy}", "creationDate": "2018-11-06T18:35:57.782379Z", "updatedDate": "2018-11-06T18:35:57.782379Z", "createdBy": "Masked value", "targetUrl": null }, { "id": 4, "state": "succeeded", "description": "PR title format", "context": "@{name=check-title; genre=my-pr-policy}", "creationDate": "2018-11-06T18:46:37.2627154Z", "updatedDate": "2018-11-06T18:46:37.2627154Z", "createdBy": "Masked value", "targetUrl": null }, { "id": 5, "state": "succeeded", "description": "Build for last update", "context": "@{name=check-build; genre=my-pr-policy}", "creationDate": "2018-11-06T18:51:33.7920543Z", "updatedDate": "2018-11-06T18:51:33.7920543Z", "createdBy": "Masked value", "targetUrl": null }, { "id": 6, "state": "failed", "description": "PR title format", "context": "@{name=check-title; genre=my-pr-policy}", "creationDate": "2018-11-06T18:53:44.3075889Z", "updatedDate": "2018-11-06T18:53:44.3075889Z", "createdBy": "Masked value", "targetUrl": null }, { "id": 7, "state": "failed", "description": "Title format is not correct", "context": "@{name=check-title; genre=my-pr-policy}", "creationDate": "2018-11-06T19:26:11.3019433Z", "updatedDate": "2018-11-06T19:26:11.3019433Z", "createdBy": "Masked value", "targetUrl": null } ], "count": 7 }
現在のステータスのリストを確認した後、リストで選択したインデックスを更新できます。 これを行うには、 Updateメソッドを使用します 。
最後に、 Deleteメソッドを使用してステータスレコードを削除できます。
PRステータス変更の履歴は、さらに分析するのに役立ちます。 したがって、次の方法でステータスを変更します。
- 同じコンテキストの最新のステータスレコードを見つける
- 追加したい同じ結果値、説明、リンクがある場合、何もしません
- それ以外の場合は、新しいステータスレコードを追加します。
これにより、変更を大きく膨らませることなく、変更の履歴を保持できます。
function Set-PullRequestStatus { param( [Parameter (Mandatory = $true)] [string] $pullRequestId, [Parameter (Mandatory = $true)] [string] $state, [Parameter (Mandatory = $true)] [string] $description, [Parameter (Mandatory = $true)] [string] $contextName, [Parameter (Mandatory = $false)] [string] $contextGenre, [Parameter (Mandatory = $false)] [string] $targetUrl, [Parameter (Mandatory = $true)] [object] $context ) $b = @{ state = $state; description = $description; context = @{ name = $contextName; genre = $contextGenre; }; targetUrl = $targetUrl; } $body = ConvertTo-Json $b # # Get current list of statuses # $endpoint = (Get-ProjectBaseURL) + "/_apis/git/repositories/{repositoryId}/pullRequests/{pullRequestId}/statuses?api-version=4.1-preview.1" $res = Get-AzureRequestReqults -URI $endpoint -context ($context + @{pullRequestId = $pullRequestId}) # # Try to find a status for a given context genre and name. Start looking from the last one. If found - check if it has same values. # $i = $res.count $foundSameStatus = $false while ($i -GT 0) { $r = $res.value[$i-1] if (($r.context.name -EQ $contextName) -AND ($r.context.genre -EQ $contextGenre)) { $foundSameStatus = ($r.state -EQ $state) -AND ($r.description -EQ $description) -AND ($r.targetUrl -EQ $targetUrl) break } $i-- } $res = $r # # If same status / values was not found - add new record. # if (-not $foundSameStatus) { $endpoint = (Get-ProjectBaseURL) + "/_apis/git/repositories/{repositoryId}/pullRequests/{pullRequestId}/statuses?api-version=4.1-preview.1" $res = Get-AzureRequestReqults -URI $endpoint -context ($context + @{pullRequestId = $pullRequestId}) -method POST -query $body } return @{status = $res; status_changed = $(-not $foundSameStatus)} }
実用化
統合ブランチへの変更を受け入れるために、かなり保守的なアプローチを採用しました。 機能ブランチの最大値への変更を最大値までテストします。
カスタムポリシーの一部として、PRステータスを使用して解決するタスクの一部を次に示します。
- すべてのPRは同じスタイルで装飾する必要があります。 したがって、作成された最初のコントロールはPRヘッダーの設計です。 正規表現と照合します。
- PRブランチは、それが注がれるブランチに遅れてはなりません（統合が行われます）。
- PRのフレームワーク内でデータベースプロジェクトのファイルが変更された場合、自動テストファイルも存在する必要があります。
- 最後の変更のためにブランチのアセンブリが成功しました。
- このようなアセンブリはテストベンチに正常に送られ、自動テストに合格しました。
リストされた条件は手動で確認できます。 前にこれをやった。 しかし、これは日常的な作業であり、自動化されたプロセスに置き換えられています。 これで、一連のチェックを補完および変更できます。常にプロセスに統合され、常に実行されます。
ポリシーの追加の巨大なプラス-それらは誰にも透過的であり、常に目に見える-PRページで。 彼らはもはや思い出させる必要はありません。
さらに、検証に失敗したポリシーについては、Wikiページへのリンクとポリシーの説明と予想されるアクションを表示します。
ポリシー施行の技術的実装
現在、ポリシーロジックはpowershellスクリプトの形式で実装されています。 高レベルのコマンドレットと優れたオブジェクトデータモデルにより、スクリプトコードは非常にコンパクトです。 また、スクリプトを段階的に対話形式で実行し、変数をいじくり回す機能により、開発とデバッグのプロセスがはるかに簡単になります。
ところで、powershellコアのリリース後、スクリプトは他のプラットフォームで実行できます（MacOSでテスト済み）。
VSTSの特別リリースで、数時間に1回程度のスケジュールでスクリプトを実行します。 シェダーをより頻繁に走り始めるかもしれません。
もちろん、このアプローチでは、Azure Functionの形式で同じものを実装し、Webフックを介してVSTSに接続する場合よりも応答が大幅に遅くなります。 しかし、私たちにとっては、チェックを実装し、これがプロセスでどのように機能するかを確認することがより重要でした（MVP）。 チェックの効率はまだ重要ではありません。 これが次のステップです。
チェックで使用されるVSTS REST APIを操作するためのライブラリの実装、およびこれらのポリシーの一部を実装する小さな例は、 GitHubのリポジトリにあります 。 誰かがそれを役に立つと思うことを願っています。