Azure Static Web Appsのブランチ環境機能を使ってみた

いわさです。

Azure Static Web Appsを使うと、静的コンテンツのホスティング&CI/CD環境を簡単に用意することが出来ます。
公開環境以外に、プルリクエストを作成すると一時的な「ステージング環境」を作成する機能があったのですが、今回のアップデートで、プルリクエストではなくブランチに紐づく永続的なプレビュー用環境を用意することが出来るようになりました。

これは最高な機能だと思いますね。早速試してみました。

本機能は本日時点でパブリックプレビューです

普通のデプロイ

おさらいがてら、まずは普通にStatic Web Appsを作ります。
AzureポータルでStatic Web Appsを作成する際にgitリポジトリの情報を含めて構成します。
そうすると、自動でデプロイパイプラインが構築され、アプリケーションがデプロイされます。

ブランチはいつものこれを使っています。

Static Web AppsにはTierとしてFreeとStandardの２種類が存在します。
一部機能はStandardでのみ利用出来るものもあるのですが、今回の機能はFreeでも利用が可能です。嬉しい。
ポータル画面からポチポチするだけなのでデプロイ手順は割愛します。デプロイ後にHTTPクライアントでアクセスしてみました。

$ curl https://salmon-sea-0f9b94100.1.azurestaticapps.net/
hoge

ではここで、mainブランチに変更を直接プッシュしてみます。
これだけでも全然すごいと思うんですけどね。自動化って素晴らしい。

$ curl https://salmon-sea-0f9b94100.1.azurestaticapps.net/
hoge add direct main

すぐに変更が環境に反映されました。

従来のステージング機能

さて、次はステージング機能をおさらいします。
こちらは以前紹介させて頂いたことがあります。

紐付けたブランチ（ここではmain）に対してプルリクエストが作成されると、本番環境と別でプルリクエストのマージ元の内容でステージング環境が自動作成されます。プルリクエストのレビュー中に変更後の動作確認が出来ますね。
これもすごく良い機能だと思います。

先程の本番環境であるmainブランチに対してプルリクエストを作成すると、プレビュー環境（以前はステージング環境と呼ばれていた）が作成されます。
URLは以下のように一時的なものが作成されます。

$ curl https://salmon-sea-0f9b94100-2.eastasia.1.azurestaticapps.net
hoge add direct main
add hoge branch

ただし、このURLはプルリクエストごとに都度生成されるもので、固定化されたものではありませんでした。
以下は追加で作成したプルリクエストで作成された環境のURLです。

$ curl https://salmon-sea-0f9b94100-3.eastasia.1.azurestaticapps.net
hoge add direct main
add hoge branch
add hoge2 branch

ブランチ環境

今回登場した機能は、本番環境として指定したブランチ以外のブランチから環境を作成することが出来ます。
特徴としてはURLにブランチ名が使われるので、プルリクエスト時のプレビュー環境と違って、デプロイタイミングごとにURLが変わりません。

また、プルリクエストの際はプルリクエストがクローズされると本番環境へ反映されてプレビュー環境は削除されました。
ブランチごとのプレビュー環境はプルリクエストに関連した動きをしないので永続的に残すことが出来ます。

早速設定してみましょう。 デフォルトではどのブランチもこの機能は動作しません。
動作させるためには、GitHub Actionsのワークフローを修正する必要があります。本日時点でポータルから設定は出来ません。

name: Azure Static Web Apps CI/CD

on:
  push:
    branches:
      - main
      - develop
  pull_request:
    types: [opened, synchronize, reopened, closed]
    branches:
      - main

jobs:
  build_and_deploy_job:
    if: github.event_name == 'push' || (github.event_name == 'pull_request' && github.event.action != 'closed')
    runs-on: ubuntu-latest
    name: Build and Deploy Job
    steps:
      - uses: actions/checkout@v2
        with:
          submodules: true
      - name: Build And Deploy
        id: builddeploy
        uses: Azure/static-web-apps-deploy@v1
        with:
          azure_static_web_apps_api_token: ${{ secrets.AZURE_STATIC_WEB_APPS_API_TOKEN_SALMON_SEA_0F9B94100 }}
          repo_token: ${{ secrets.GITHUB_TOKEN }} # Used for Github integrations (i.e. PR comments)
          action: "upload"
          ###### Repository/Build Configurations - These values can be configured to match your app requirements. ######
          # For more information regarding Static Web App workflow configurations, please visit: https://aka.ms/swaworkflowconfig
          app_location: "/" # App source code path
          api_location: "" # Api source code path - optional
          output_location: "" # Built app content directory - optional
          ###### End of Repository/Build Configurations ######
          production_branch: "main"

  close_pull_request_job:
:

上記ハイライト部分(２行)を追加しています。
developブランチでもデプロイを行うことと、運用環境はmainブランチであることを指定しています。
これで、developブランチをプッシュした際に非運用環境としてデプロイがされます。

URLは以下のようになります。

$ curl https://salmon-sea-0f9b94100-develop.eastasia.1.azurestaticapps.net/
hoge add direct main
add hoge branch
add hoge2 branch
add develop branch

URLが固定化されているので、パイプラインからプルリクエスト前の自動テストをパスさせるることも出来そうですね。
より、ステージング環境に近い使い方が出来るようになります。

ちなみに、ここからプルリクエストを作るとプルリクエストによるプレビュー環境も追加で作られます。

もちろんその環境はマージされれば削除されるのですが、developブランチによって作成されたプレビュー環境は残り続けるということです。

プルリクエストをマージしても、ブランチを消しても残る

プルリクエストのマージ後にリモートブランチを削除するケース多いと思いますが、ブランチを削除すると環境はどうなるでしょうか。

確認しましたが、ブランチが削除されても環境は残り続けます。
環境を削除する際には以下から明示的に削除する必要があります。

ちなみに、devleopブランチを削除した後に、またdevelopブランチを作成すると、既存のプレビュー環境（同一ブランチ名）が更新されました。
よく出来てますね。

$ curl https://salmon-sea-0f9b94100-develop.eastasia.1.azurestaticapps.net/
hoge develop

最大数

複数の環境が作成出来るわけですが、最大数があるのでそこだけ気をつけておきましょう。
プルリクエストによるステージング環境の場合はFreeの場合だと最大３つまでの制限事項があるとドキュメントに明記されています。

The number of pre-production environments available for each app deployed with Static Web Apps depends on the hosting plan you are using. For example, with the Free tier you can have 3 pre-production environments in addition to the production environment.

以下のように対象ブランチを追加し、リモートブランチを作成してみましょう。

name: Azure Static Web Apps CI/CD

on:
  push:
    branches:
      - main
      - develop
      - develop2
      - develop3
      - develop4
      - develop5
  pull_request:
    types: [opened, synchronize, reopened, closed]
    branches:
      - main

:

確認してみると、途中でGitHub Actionsの環境作成に失敗しました。
どうやら、プルリクエストとブランチどちらもカウントの対象のようです。
ドキュメントのようにFreeの場合だと運用環境1つ＋プレビュー環境3つまでが最大となっていて、そこから追加のブランチやプルリクエストは以下のようにアクションが失敗しますのでご注意ください。

The content server has rejected the request with: BadRequest Reason: This Static Web App already has the maximum number of staging environments (3). Please remove one and try again.

さいごに

本日はAzure Static Web Appsのブランチ環境機能をためしてみました。
これはもうすぐに使いたい最高な機能ですね。GAが待ち遠しいところです。
フィードバックどんどんしましょう。ポータルで初期作成時に非運用ブランチを指定出来るようになるとかも期待したいところですね。