演習 - メインブランチを保護する

5 分

チームでは、既に Web サイトとデータベースが含まれている Bicep テンプレートに取り組んでいます。あなたは、コンポーネントを運用環境にデプロイしました。ここでは、Bicep テンプレートを更新して、注文処理キューを追加する必要があります。

この演習では、変更のための機能ブランチを作成します。また、メインブランチを保護し、レビューされた後にのみ変更をメインブランチにマージできるようにします。ただし、その前に、このモジュールの残りの部分を完了するために、環境が設定されていることを確認する必要があります。

このプロセスでは、次のことを行います。

このモジュール向けに GitHub リポジトリを設定します。
リポジトリをコンピューターに複製します。
リポジトリのメインブランチにブランチ保護を追加する。
変更のためのローカル機能ブランチを作成する。
機能ブランチをメインにマージしてみる。

このモジュール用の Azure DevOps プロジェクトを設定します。
プロジェクトのリポジトリをコンピューターにクローンする。
リポジトリのメインブランチにブランチポリシーを追加する。
変更のためのローカル機能ブランチを作成する。
機能ブランチをメインにマージしてみる。

GitHub リポジトリを取得する

ここで、このモジュールの残りの部分を完了するために GitHub リポジトリが設定されていることを確認します。テンプレートリポジトリに基づいて新しいリポジトリを作成することによって、設定します。テンプレートリポジトリには、このモジュールを開始するために必要なファイルが含まれています。

テンプレートリポジトリから開始する

GitHub リポジトリを設定するテンプレートを実行します。

テンプレートの実行

GitHub サイトで、次の手順を実行して、テンプレートからリポジトリを作成します。

[このテンプレートを使用]>[新しいリポジトリの作成] の順に選択します。
新しいプロジェクトに、「toy-website-review」などの名前を入力します。
[Public](パブリック) オプションを選択します

独自のリポジトリを作成するときに、プライベートにしたい場合もあります。このモジュールでは、パブリックリポジトリと GitHub Enterprise アカウントでのみ動作する GitHub 機能を使用して作業します。
[Create repository from template](テンプレートからリポジトリを作成する) を選択します。

Azure DevOps プロジェクトを取得する

ここでは、このモジュールの残りの部分を完了するために、Azure DevOps 組織が確実に設定されるようにします。これを設定するには、Azure DevOps でテンプレートを実行して、プロジェクトを作成します。

テンプレートの実行

Azure DevOps Demo Generator サイトで、次の手順に従います。

[サインイン] を選択して利用規約に同意します。
[新しいプロジェクトの作成] ページで、ご自分の Azure DevOps 組織を選択します。次に、「toy-website-review」などのプロジェクト名を入力します。
[プロジェクトの作成] を選択します。

テンプレートの実行には少し時間がかかります。パイプラインと Bicep ファイルが自動的に作成されます。これは、後の演習で使用します。
[プロジェクトに移動] を選択して Azure DevOps のプロジェクトに移動します。

リポジトリの複製

これで、独自のアカウントでテンプレートリポジトリのコピーが作成されました。このリポジトリをローカルにクローンし、その中で作業を開始できるようにします。

[コード] を選択し、[コピー] アイコンを選択します。
Visual Studio Code を開きます。
[ターミナル]>[新しいターミナル] を選択して、Visual Studio Code ターミナルウィンドウを開きます。このウィンドウは通常、画面の下部に表示されます。
ターミナルで、ローカルコンピューター上に GitHub リポジトリをクローンしたいディレクトリに移動します。たとえば、toy-website-review フォルダーにリポジトリをクローンするには、次のコマンドを実行します。
```
cd toy-website-review
```
「git clone」と入力して先ほどコピーした URL を貼り付け、コマンドを実行します。次のようなコマンドです。
```
git clone https://github.com/mygithubuser/toy-website-review.git
```
Visual Studio Code ターミナルで次のコマンドを実行して、リポジトリフォルダー内の Visual Studio Code を再度開きます。
```
code -r toy-website-review
```

これで、独自のアカウント内にプロジェクトが作成されました。このリポジトリをローカルにクローンし、その中で作業を開始できるようにします。

[Repos]>[ファイル] を選択します。
[複製] を選択します。
macOS を使用している場合は、Git リポジトリをクローンするための特別なパスワードが必要です。 [Git 資格情報の生成] を選択し、表示されるユーザー名とパスワードを安全な場所にコピーします。
[Clone in VS Code](VS コードにクローンする) を選択します。 Visual Studio Code を開くことを許可するように求めるメッセージが表示されたら、[開く] を選択します。
リポジトリ用に使用するフォルダーを作成してから、[リポジトリの場所を選択] を選択します。
このリポジトリを使用するのは初めてなので、サインインするように求められます。
- Windows を使用している場合は、この演習で以前に Azure DevOps にサインインするために使用したのと同じ資格情報を入力します。
- macOS を使用している場合は、先ほど生成した Git ユーザー名とパスワードを入力します。
Visual Studio Code からリポジトリを開くように求められます。 [Open (開く)] を選択します。

ブランチ保護を追加する

メインブランチへの直接プッシュを防止するように Git リポジトリを構成します。

ブラウザーで、[Settings](設定) を選択します。
[Branches](ブランチ) を選択します。
[ブランチ保護ルールの追加] を選択します。
[Branch name pattern](ブランチ名パターン) テキストボックスに「main」と入力します。
[Require a pull request before merging](マージ前に pull request を要求する) を選択します。

[Require approvals](承認を要求する) をクリアします。通常は、このオプションをオンにします。しかし、この例では、独自の pull request マージします。[Require approvals](承認を要求する) オプションでは、それが防止されます。
[上記の設定をバイパスすることを許可しない] を選択します。

この演習の後半で git push から main がどのように失敗するかを示す例として、この設定を選択します。運用環境では、管理者またはリポジトリ所有者に対して、main への直接マージを制限したくない場合があります。
ページの下部にある [Create](作成) を選択します。

GitHub から、本人確認のためにもう一度サインインするよう要求される場合があります。

ブランチポリシーを追加する

メインブランチへの直接プッシュを防止するように Git リポジトリを構成します。

ブラウザーで、[リポジトリ]>[ブランチ] に移動します。
main ブランチの上にカーソルを置き、3 つのドットを選択します。
[ブランチポリシー] を選択します。
[ブランチポリシー] ウィンドウで、[レビュー担当者の最少数が必要です] 設定を [オン] に変更します。
レビュー担当者の最小数を 1 に変更し、[Allow requestors to approve their own changes](要求者が自分の変更を承認することを許可する) オプションをオンにします。

Note

ここでは、[Allow requestors to approve their own changes](要求者が自分の変更を承認することを許可する) オプションを有効にしています。これらの演習では自分で作業しているため、自分で変更を作成して承認する必要があります。しかし、実際のチーム環境では、このオプションを有効にしない場合があります。

ローカル機能ブランチを作成する

Visual Studio Code ターミナルで、次のステートメントを実行します。
```
git checkout -b add-orders-queue
```
このコマンドを実行すると、作業の起点となる新しい機能ブランチが作成されます。
deploy フォルダーの main.bicep ファイルを開きます。

パラメーターの下に、キューの名前の新しい変数を追加します。

var storageAccountSkuName = (environmentType == 'prod') ? 'Standard_GRS' : 'Standard_LRS'
var processOrderQueueName = 'processorder'

ストレージアカウントのリソース内に、入れ子になった子リソースとしてキューを追加します。

resource storageAccount 'Microsoft.Storage/storageAccounts@2022-09-01' = {
  name: storageAccountName
  location: location
  sku: {
    name: storageAccountSkuName
  }
  kind: 'StorageV2'
  properties: {
    accessTier: 'Hot'
  }

  resource queueServices 'queueServices' existing = {
    name: 'default'

    resource processOrderQueue 'queues' = {
      name: processOrderQueueName
    }
  }
}

appService モジュール定義に、ストレージアカウントとキュー名をパラメーターとして追加します。

module appService 'modules/appService.bicep' = {
  name: 'appService'
  params: {
    location: location
    appServiceAppName: appServiceAppName
    storageAccountName: storageAccount.name
    processOrderQueueName: storageAccount::queueServices::processOrderQueue.name
    environmentType: environmentType
  }
}

このコードにより、アプリケーションはメッセージを送信するキューを見つけられるようになります。

main.bicep ファイルを保存します。
deploy/modules フォルダーの appService.bicep ファイルを開きます。

appService.bicep ファイルの上部付近に、ストレージアカウントとキュー名の新しいパラメーターを追加します。

@description('The Azure region into which the resources should be deployed.')
param location string

@description('The name of the App Service app to deploy. This name must be globally unique.')
param appServiceAppName string

@description('The name of the storage account to deploy. This name must be globally unique.')
param storageAccountName string

@description('The name of the queue to deploy for processing orders.')
param processOrderQueueName string

@description('The type of the environment. This must be nonprod or prod.')
@allowed([
  'nonprod'
  'prod'
])
param environmentType string

appServiceApp リソースを更新して、ストレージアカウントとキュー名をアプリケーションの環境変数に反映させます。

resource appServiceApp 'Microsoft.Web/sites@2022-03-01' = {
  name: appServiceAppName
  location: location
  properties: {
    serverFarmId: appServicePlan.id
    httpsOnly: true
    siteConfig: {
      appSettings: [
        {
          name: 'StorageAccountName'
          value: storageAccountName
        }
        {
          name: 'ProcessOrderQueueName'
          value: processOrderQueueName
        }
      ]
    }
  }
}

機能ブランチをコミットしてプッシュする

Visual Studio Code ターミナルで次のコマンドを実行し、変更をコミットして GitHub リポジトリにプッシュします。

Visual Studio Code ターミナルで次のコマンドを実行し、変更をコミットして Azure Repos リポジトリにプッシュします。

git add .
git commit -m "Add orders queue and associated configuration"
git push --set-upstream origin add-orders-queue

機能ブランチは、リモートリポジトリ内の新しいブランチ (これも add-orders-queue という名前) にプッシュされます。

機能ブランチをメインにマージしてみる

メインブランチに直接プッシュすべきでない理由について学習しました。ここでは、そのガイドラインに違反して、メインブランチの保護によって保護されたブランチへの変更の誤ったプッシュが防止されるしくみを確認してみます。

Visual Studio Code ターミナルで、次のステートメントを実行してメインブランチに切り替え、add-orders-queue ブランチをマージします。
```
git checkout main
git merge add-orders-queue
```
コマンドは機能しましたが、"ローカル" Git リポジトリ内でのみ add-orders-queue ブランチをメインブランチにマージしました。

次のステートメントを実行して、変更を GitHub にプッシュしてみます。

git push

プッシュが失敗すると、次のようなエラーメッセージが表示されます。

Total 0 (delta 0), reused 0 (delta 0), pack-reused 0
remote: error: GH006: Protected branch update failed for refs/heads/main.
remote: error: Changes must be made through a pull request.
To https://github.com/mygithubuser/toy-website-review.git
 ! [remote rejected] main -> main (protected branch hook declined)
error: failed to push some refs to 'https://github.com/mygithubuser/toy-website-review.git'

このエラーメッセージは、メインブランチへのプッシュが許可されず、pull request を使ってブランチを更新する必要があることを示しています。

次のステートメントを実行して、マージを元に戻します。
```
git reset --hard HEAD~1
```
このコマンドは、メインブランチの状態を前回のコミットがマージされる前の状態にリセットし、変更を保存しないようローカル Git リポジトリに指示します。 add-orders-queue ブランチは影響を受けません。

メインブランチに直接プッシュすべきでない理由について学習しました。ここでは、そのガイドラインに違反して、ブランチポリシーによって保護されたブランチへの変更の誤ったプッシュが防止されるしくみを確認してみます。

Visual Studio Code ターミナルで、次のステートメントを実行してメインブランチに切り替え、add-orders-queue ブランチをマージします。
```
git checkout main
git merge add-orders-queue
```
コマンドは機能しましたが、ローカル Git リポジトリ内でのみ add-orders-queue ブランチをメインブランチにマージしました。

次のステートメントを実行して、変更を Azure Repos にプッシュしてみます。

git push