GitHub Actions を使用して API を発行する
Web アプリに API を追加しました。両方ともローカルで実行されています。 次に、API とアプリを Azure Static Web Apps に発行します。
Azure Static Web Apps インスタンスを作成し、main ブランチを監視するように要求すると、GitHub アクションが自動的に生成されました。 GitHub アクションでは、リポジトリの main ブランチへのコミットと pull request がリッスンされます。 その後、GitHub アクションでこれらの変更が検出されると、アプリがビルドされ、発行されます。
Azure Static Web Apps リソースを作成したときに、Api の既定値を受け入れて、API プロジェクトのフォルダーの場所を指定しました。 Azure Static Web Apps によって、そのフォルダーに Azure Functions アプリが構築されてデプロイされました。 しかし、HTTP GET API がまだ作成されていないため、そのアプリは機能しませんでした。
GitHub アクションをトリガーする
GitHub アクションは、main ブランチへの変更が検出されたときに Web アプリと API をビルドして発行できる状態になっています。 直接コミットすることも、main ブランチに pull request を作成することもできます。 どちらの変更でも GitHub アクションがトリガーされます。 main ブランチで変更が検出されると、GitHub アクションがトリガーされ、ライブ Web サイトと同じ URL にアプリが発行されます。
プレビュー URL を持つ運用前環境
ライブ Web サイトに発行する前に、ステージング サイトで変更を確認する場合があります。 Azure Static Web Apps を使うと、それぞれが独自のプレビュー URL を持つ運用前環境で変更を確認できます。 運用前環境を作成するには、GitHub アクションの監視対象であるブランチに対して pull request を作成します。 ライブ Web サイトは影響を受けません。 代わりに、独自の運用前環境に、アプリの新しいバージョンが作成されます。 前に戻って GitHub で pull request を確認すると、[会話] タブに運用前バージョンへのリンクが表示されていることがわかります。
Azure Static Web Apps から別の URL にアプリを発行する方法を次の表に示します。 アプリはある URL に発行されますが、同じブランチへの pull request は別の URL に発行されます。 これらの自動生成された URL は、運用アプリと pull request 用に Azure Static Web Apps によって提供されます。 必要に応じて、カスタム ドメインを運用アプリに割り当てることができます。
| source | 説明 | URL |
|---|---|---|
| main ブランチ | ライブ Web サイトの URL の例 | https://purple-rain-062d03304.azurestaticapps.net/ |
| Pull Request #5 | プレビュー URL の例 | https://purple-rain-062d03304-5.<location>.azurestaticapps.net/ |
現在は api ブランチで作業しています。 api ブランチから main ブランチに対して pull request を行います。 main ブランチに対して pull request を作成すると、GitHub アクションによって、アプリが運用前環境に発行されます。
ワークフローでアプリのビルドとデプロイが完了すると、GitHub ボットによって pull request にコメントが追加されます。 このコメントには、運用前環境の URL へのリンクが含まれています。 このリンクを選択すると、ステージされている変更を確認できます。
次に、pull request を作成し、アプリのステージング バージョンにアクセスします。