1636111860
AzureDevOpsサービスを使用してゲート付きチェックインポリシーを設定する
ゲート付きのチェックインは、ソース管理システム-何か、すべてのソフトウェア会社を設立しようとに分かれコードをマージから制限し、開発者、そのプロセスです。その際、組織はいくつかの質問をする必要があります。
このガイドでは、これらの質問を明確にし、Azure DevOps Services（旧称VSTS）を使用してゲートチェックインプロセス用に構成できるさまざまなポリシーを設定する方法を明らかにします。
ブランチポリシーと関連機能について学ぶことから始めましょう。
ブランチを保護する
Azure DevOpsには、ゲートチェックインプロセスを設定するために使用されるブランチポリシーと呼ばれる機能があります。ブランチポリシーは、チームが開発の重要なブランチを保護するのに役立ちます。ポリシーは、コード品質を向上させ、コード標準の管理を改善するためにチームに適用されます。
簡単に言うと、次のポリシーを設定できます。
次に、各ポリシーを詳しく調べて、ゲート付きチェックインプロセスにブランチポリシー機能の機能を活用します。次のセクションでは、各ポリシーについて詳しく説明し、ブランチポリシーを構成するためのヒントを示します。
ブランチポリシーを構成する
ブランチポリシーを設定するには、次の図に示すように、[リポジトリ]> [ブランチ]に移動します。
あなたはをクリックすると支店のオプションは、起動支店下図のように、ウェブポータルのページを。
[ … ]ボタンを選択し、コンテキストメニューから[ブランチポリシー]を選択します。
これで、設定ページでさまざまなポリシーを構成できます。各ポリシータイプの説明については、ガイドの残りの部分を参照してください。
レビューアの最小数を設定する
査読者の最小数必要ポリシーは、ほとんどのソフトウェア開発プロジェクトを支援します。コードレビューは、従うべきベストプラクティスであり、コード品質を確実に向上させるための推奨される方法です。
プルリクエストを完了する前にチームに変更のレビューを要求するには、[最小数のレビューアを要求する]オプションを選択します。ベストプラクティスとして、最低2人のレビューアを設定することをお勧めします。
このポリシーは、開発者のコードがマスターブランチにマージされる前に、すべてのソフトウェア業界にも役立ちます。最小数のレビューアとともにポリシーを構成するためのさまざまなオプションを提供します。これらのオプションについて詳しく見ていきましょう。
リクエスターが自分の変更を承認できるようにする
このオプションが選択されている場合、プルリクエストの作成者はその承認に投票できます。そうでない場合、彼らの投票はレビューアの最小数にカウントされません。プルリクエストの作成者は、自分のリクエストに投票できないようにすることをお勧めします。
最新のプッシャーが自分の変更を承認することを禁止する
このオプションを有効にすると、強制的な職務分掌が発生します。これは、最新のプッシュが自動的にプッシャーの投票をカウントしないことを意味します。
一部のレビューアが待機または拒否に投票した場合でも、完了を許可する
このオプションが有効になっていない場合、一部のレビューアが拒否することに投票した場合、リクエストコードのプルはマスターブランチにマージされません。必要な場合を除いて、このオプションを有効にしないことをお勧めします。
新しい変更がある場合は、コードレビューアの投票をリセットします
このオプションを使用すると、プルリクエストの作成者が同じPRに新しい変更を送信した場合に、コードレビューアの投票をリセットできます。このようにして、レビュー担当者は新しい変更を十分に認識しており、PRを承認するかどうかを決定できます。
関連する作業項目のチェックを設定する
このポリシーは、プルリクエストとワークアイテムの間に関連付けを設定して、ブランチへの今後の変更が適切なトレーサビリティを持つようにする機能を提供します。
このポリシーを必須またはオプションとして設定して、プルリクエストで関連する作業項目を確認できます。必要に応じてこのオプションを設定することをお勧めします。これは、ユーザーが少なくとも1つのリンクされた作業項目を持っていない限り、プル要求が完了しないようにブロックすることを意味します。
コメント解決を実施する
同様に、ブランチポリシーは、コメントがアクティブな間、プルリクエストが完了しないようにブロックする機能を提供します。
Azure DevOpsには、必須とオプションの2つのオプションがあります。すべてのコメントが解決されない限り、ユーザーがPRを完了できないように、必要に応じてこのオプションを設定することをお勧めします。
ビルド検証を設定する
ビルド検証の設定は、ゲートチェックインプロセスの重要な部分です。このオプションを使用すると、コード品質をより細かく制御でき、すべてのユニットテストまたは統合テストに合格する必要がある、SonarQubeコード品質ゲートが承認される、ビルドが成功するなど、さまざまなプロセスを使用してコードを保護できます。
ビルドポリシーは、中断を減らし、テスト結果の合格を維持します。開発ブランチの継続的インテグレーション（CI）と非常によく統合して、問題を早期に発見できます。
このポリシーを設定する前に、ビルドパイプラインを稼働させることが前提条件です。ビルドポリシーには、ソースブランチが更新されたときにトリガーされるパイプラインが必要です。このポリシーは、セットアップ中にオプションを提供します。
1.トリガーオプション
2.ポリシー要件
3.ビルドの有効期限
コードレビューアを自動的に含める
このフィルターは、新しいプルリクエストが送信されたときにコードレビューアを自動的に含める機能を提供します。このポリシーを構成するには、次の図に示すように、チームがレビュー担当者の名前とポリシー要件を決定する必要があります。
結論
このガイドでは、ブランチポリシー機能を使用してAzureDevOpsでゲートチェックインプロセスを構成する方法について学習しました。全体として、これはチームがより良いプロセスを設定し、コード品質を改善し、ビジネス上の問題に集中するのに役立ちます。
このガイドをさらに発展させるために、パスフィルタ、バイパスブランチポリシー、ステータスチェックなどの他のオプションを設定できます。Azure DevOpsは、それらを実装するためのブランチアクセス許可（セキュリティ）機能を提供します。読んでくれてありがとう。
リンク: https://www.pluralsight.com/guides/set-up-a-gated-check-in-policy-in-vsts
What is GEEK
Buddha Community
1636111860
AzureDevOpsサービスを使用してゲート付きチェックインポリシーを設定する
ゲート付きのチェックインは、ソース管理システム-何か、すべてのソフトウェア会社を設立しようとに分かれコードをマージから制限し、開発者、そのプロセスです。その際、組織はいくつかの質問をする必要があります。
このガイドでは、これらの質問を明確にし、Azure DevOps Services（旧称VSTS）を使用してゲートチェックインプロセス用に構成できるさまざまなポリシーを設定する方法を明らかにします。
ブランチポリシーと関連機能について学ぶことから始めましょう。
ブランチを保護する
Azure DevOpsには、ゲートチェックインプロセスを設定するために使用されるブランチポリシーと呼ばれる機能があります。ブランチポリシーは、チームが開発の重要なブランチを保護するのに役立ちます。ポリシーは、コード品質を向上させ、コード標準の管理を改善するためにチームに適用されます。
簡単に言うと、次のポリシーを設定できます。
次に、各ポリシーを詳しく調べて、ゲート付きチェックインプロセスにブランチポリシー機能の機能を活用します。次のセクションでは、各ポリシーについて詳しく説明し、ブランチポリシーを構成するためのヒントを示します。
ブランチポリシーを構成する
ブランチポリシーを設定するには、次の図に示すように、[リポジトリ]> [ブランチ]に移動します。
あなたはをクリックすると支店のオプションは、起動支店下図のように、ウェブポータルのページを。
[ … ]ボタンを選択し、コンテキストメニューから[ブランチポリシー]を選択します。
これで、設定ページでさまざまなポリシーを構成できます。各ポリシータイプの説明については、ガイドの残りの部分を参照してください。
レビューアの最小数を設定する
査読者の最小数必要ポリシーは、ほとんどのソフトウェア開発プロジェクトを支援します。コードレビューは、従うべきベストプラクティスであり、コード品質を確実に向上させるための推奨される方法です。
プルリクエストを完了する前にチームに変更のレビューを要求するには、[最小数のレビューアを要求する]オプションを選択します。ベストプラクティスとして、最低2人のレビューアを設定することをお勧めします。
このポリシーは、開発者のコードがマスターブランチにマージされる前に、すべてのソフトウェア業界にも役立ちます。最小数のレビューアとともにポリシーを構成するためのさまざまなオプションを提供します。これらのオプションについて詳しく見ていきましょう。
リクエスターが自分の変更を承認できるようにする
このオプションが選択されている場合、プルリクエストの作成者はその承認に投票できます。そうでない場合、彼らの投票はレビューアの最小数にカウントされません。プルリクエストの作成者は、自分のリクエストに投票できないようにすることをお勧めします。
最新のプッシャーが自分の変更を承認することを禁止する
このオプションを有効にすると、強制的な職務分掌が発生します。これは、最新のプッシュが自動的にプッシャーの投票をカウントしないことを意味します。
一部のレビューアが待機または拒否に投票した場合でも、完了を許可する
このオプションが有効になっていない場合、一部のレビューアが拒否することに投票した場合、リクエストコードのプルはマスターブランチにマージされません。必要な場合を除いて、このオプションを有効にしないことをお勧めします。
新しい変更がある場合は、コードレビューアの投票をリセットします
このオプションを使用すると、プルリクエストの作成者が同じPRに新しい変更を送信した場合に、コードレビューアの投票をリセットできます。このようにして、レビュー担当者は新しい変更を十分に認識しており、PRを承認するかどうかを決定できます。
関連する作業項目のチェックを設定する
このポリシーは、プルリクエストとワークアイテムの間に関連付けを設定して、ブランチへの今後の変更が適切なトレーサビリティを持つようにする機能を提供します。
このポリシーを必須またはオプションとして設定して、プルリクエストで関連する作業項目を確認できます。必要に応じてこのオプションを設定することをお勧めします。これは、ユーザーが少なくとも1つのリンクされた作業項目を持っていない限り、プル要求が完了しないようにブロックすることを意味します。
コメント解決を実施する
同様に、ブランチポリシーは、コメントがアクティブな間、プルリクエストが完了しないようにブロックする機能を提供します。
Azure DevOpsには、必須とオプションの2つのオプションがあります。すべてのコメントが解決されない限り、ユーザーがPRを完了できないように、必要に応じてこのオプションを設定することをお勧めします。
ビルド検証を設定する
ビルド検証の設定は、ゲートチェックインプロセスの重要な部分です。このオプションを使用すると、コード品質をより細かく制御でき、すべてのユニットテストまたは統合テストに合格する必要がある、SonarQubeコード品質ゲートが承認される、ビルドが成功するなど、さまざまなプロセスを使用してコードを保護できます。
ビルドポリシーは、中断を減らし、テスト結果の合格を維持します。開発ブランチの継続的インテグレーション（CI）と非常によく統合して、問題を早期に発見できます。
このポリシーを設定する前に、ビルドパイプラインを稼働させることが前提条件です。ビルドポリシーには、ソースブランチが更新されたときにトリガーされるパイプラインが必要です。このポリシーは、セットアップ中にオプションを提供します。
1.トリガーオプション
2.ポリシー要件
3.ビルドの有効期限
コードレビューアを自動的に含める
このフィルターは、新しいプルリクエストが送信されたときにコードレビューアを自動的に含める機能を提供します。このポリシーを構成するには、次の図に示すように、チームがレビュー担当者の名前とポリシー要件を決定する必要があります。
結論
このガイドでは、ブランチポリシー機能を使用してAzureDevOpsでゲートチェックインプロセスを構成する方法について学習しました。全体として、これはチームがより良いプロセスを設定し、コード品質を改善し、ビジネス上の問題に集中するのに役立ちます。
このガイドをさらに発展させるために、パスフィルタ、バイパスブランチポリシー、ステータスチェックなどの他のオプションを設定できます。Azure DevOpsは、それらを実装するためのブランチアクセス許可（セキュリティ）機能を提供します。読んでくれてありがとう。
リンク: https://www.pluralsight.com/guides/set-up-a-gated-check-in-policy-in-vsts