Azure Repos での pull request を使用した共同作業演習

• 60 分

コードの問題がより早く見つかると、修正が容易で、しかもより安価になります。 そのため、開発チームは、コード品質チェックを開発プロセスのできるだけ早い段階に組み込むように努力します。

名前が示しているように、ブランチ ポリシーは、サーバー上のブランチに適用可能なすぐに使用できる一連のポリシーを提供します。

サーバー ブランチにプッシュされる変更はすべて、受け入れられるには、これらのポリシーに従っている必要があります。

ポリシーは、チームのコード品質と変更管理の標準を適用するための優れた方法です。 このレシピでは、メイン ブランチ上でブランチ ポリシーを構成する方法を学習します。

開発の準備

すぐに使用できるブランチ ポリシーには、ビルドの検証やマージ戦略の適用などのいくつかのポリシーが含まれています。 ここでは、このレシピでコード レビュー ワークフローを設定するために必要なブランチ ポリシーにのみ焦点を絞ります。

方法

1. Parts Unlimited チーム ポータルで、myWebApp Git リポジトリのブランチのビューを開きます。 メイン ブランチを選択し、プルダウンのコンテキスト メニューから [ブランチ ポリシー] を選択します。

   

2. [ポリシー] ビューには、すぐに使用できるポリシーが表示されます。 レビュー担当者の最小数を 1 に設定します。

   

   [要求者が自分の変更を承認することを許可する] オプションを使用すると、提出者は自分の変更を自己承認できるようになります。

   これは成熟したチームでは許容されるかもしれませんが、一般的には避ける必要があります。
   

3. レビュー ポリシーをコメント解決ポリシーと共に使用します。 これにより、コード レビューのコメントを、変更が受け入れられる前に強制的に解決できます。 要求者は、コメントからフィードバックを受け取り、新しい作業項目を作成して変更を解決できます。 これにより、少なくとも、コードのメイン ブランチへの受け入れでコード レビューのコメントが失われないことが保証されます。

   

4. 要件により、チーム プロジェクトでのコード変更が発生します。 この作業をトリガーした作業項目が変更にリンクされていないと、時間の経過と共に、それが行われた理由を理解することが難しくなります。 これは、変更の履歴をレビューするときに特に役立ちます。 リンクされている作業項目がない変更をブロックするには、[リンクされた作業項目を確認します] ポリシーを構成します。

   

5. pull request が生成されたときにレビュー担当者を自動的に含めるオプションを選択します。 変更されるコードの領域に基づいて、どのレビュー担当者が追加されるかをマップできます。

   

しくみ

これで、ブランチ ポリシーが設定されたので、メイン ブランチが完全に保護されるようになりました。

変更をメイン ブランチにプッシュする唯一の方法として、まず別のブランチで変更を行い、次に変更受け入れワークフローをトリガーする pull request を発生させます。

作業項目ハブにある既存のユーザー ストーリーのいずれかから新しいブランチを作成することを選択します。

作業項目から新しいブランチを作成すると、そのブランチにその作業項目が自動的にリンクされます。

必要に応じて、ワークフローの作成の一部として 1 つのブランチに複数の作業項目を含めることができます。

ブランチを格納するフォルダーを作成するには、そのブランチを作成するときに名前にプレフィックスを付けます。

前の例では、このブランチはフォルダーに格納されます。 これは、ビジー状態の環境でブランチを整理するための優れた方法です。

Web ポータルで新しく作成されたブランチが選択された状態で、HomeController.cs ファイルを編集して次のコード スニペットを含め、ブランチへの変更をコミットします。

次の画像では、コミット ボタンをクリックすることにより、ファイルを編集した後に変更を直接コミットできることがわかります。

チーム ポータル内のファイル パス コントロールでは検索がサポートされます。

ファイル パスを入力し始めると、Git リポジトリ内のそのディレクトリの下にある、これらの文字で始まるすべてのファイルがファイル パスの検索結果のドロップダウンに表示されます。

Web ポータルのコード エディターには、かっこの一致や空白の表示/非表示のサポートなど、Azure DevOps Server の新機能がいくつか含まれています。

コマンド パレットを押すことによって、それを読み込むことができます。 その他の多くの新しいオプションの中では、ファイルのミニマップを使用したファイルの切り替えのほか、折りたたみや展開などの標準の操作を実行できるようになりました。

これらの変更を新しいブランチからメイン ブランチにプッシュするには、pull request のビューから pull request を作成します。

新しいブランチをソースとして、メインをターゲット ブランチとして選択します。

新しい pull request フォームではマークダウンがサポートされるため、マークダウン構文を使用して説明を追加できます。

説明ウィンドウでは、@メンションや、作業項目をリンクするための # もサポートされます。

pull request が作成され、概要ページに変更の要約とポリシーの状態が表示されます。

[ファイル] タブには、変更と以前のバージョンと現在のバージョンの違いの一覧が表示されます。

コード ファイルにプッシュされた更新はすべて [更新] タブに表示され、すべてのコミットの一覧が [コミット] タブに表示されます。

[ファイル] タブを開きます。このビューでは、行レベル、ファイル レベル、さらには全体のコードのコメントがサポートされます。

これらのコメントでは、メンションのための @ と作業項目をリンクするための # の両方がサポートされ、テキストではマークダウン構文がサポートされます。

コードのコメントは、pull request ワークフローに保持されます。コードのコメントでは、レビューの複数の反復処理がサポートされるため、入れ子になった応答で適切に動作します。

レビュー担当者ポリシーでは、変更受け入れの一部としてコード レビュー ワークフローが許可されます。

これは、チームが、メイン ブランチにプッシュされたコード変更に関して共同作業するための優れた方法です。

必要な数のレビュー担当者が pull request を承認すると、それを完了できます。

pull request をレビュー後にオートコンプリートするようにマークすることもできます。 これにより、すべてのポリシーが正常にコンパイルされると pull request がオートコンプリートされます。

その他の情報

ブランチが誤って削除された状態になったことはありますか。 何が起こったかを理解することは簡単ではありません。

Azure DevOps Server では、削除されたブランチの検索がサポートされるようになりました。 これは、だれがそれを、いつ削除したかを理解するのに役立ちます。 また、このインターフェイスを使用してブランチを再作成することもできます。

削除されたブランチは、検索結果からノイズを除去するために、その正確な名前で検索した場合にのみ表示されます。

削除されたブランチを検索するには、ブランチ検索ボックスにブランチの完全な名前を入力します。 そのテキストに一致する既存のブランチが返されます。

また、削除されたブランチの一覧には、完全一致を検索するためのオプションも表示されます。

一致が見つかった場合は、だれがそれを、いつ削除したかが表示されます。 また、そのブランチを復元することもできます。 ブランチを復元すると、最後にポイントされていたコミットで再作成されます。

ただし、ポリシーやアクセス許可は復元されません。