GitHub Actions を使用して API を発行する

Web アプリに API を追加しました。両方ともローカルで実行されています。 次に、API とアプリを Azure Static Web Apps に発行します。

Azure Static Web Apps インスタンスを作成し、 メイン ブランチを監視するように要求すると、GitHub アクションが自動的に生成されました。 GitHub アクションは、リポジトリの メイン ブランチでコミットとプル要求をリッスンします。 その後、GitHub アクションでこれらの変更が検出されると、アプリがビルドされ、発行されます。

Azure Static Web Apps リソースを作成したときに、API の既定値を受け入れることで、API プロジェクトのフォルダーの場所を指定しました。 Azure Static Web Apps によって、そのフォルダーに Azure Functions アプリが構築されてデプロイされました。 しかし、HTTP GET API がまだ作成されていないため、そのアプリは機能しませんでした。

GitHub アクションをトリガーする

GitHub アクションは、 メイン ブランチへの変更を検出したら、Web アプリと API をビルドして発行する準備ができています。 直接コミットすることも、 メイン ブランチに pull request を作成することもできます。 どちらの変更でも GitHub アクションがトリガーされます。 メイン ブランチで変更が検出されると、GitHub アクションがトリガーされ、ライブ Web サイトの同じ URL でアプリが発行されます。

プレビュー URL を持つ運用前環境

ライブ Web サイトに発行する前に、ステージング サイトで変更を確認する場合があります。 Azure Static Web Apps を使うと、それぞれが独自のプレビュー URL を持つ運用前環境で変更を確認できます。 運用前環境を作成するには、GitHub アクションの監視対象であるブランチに対して pull request を作成します。 ライブ Web サイトは影響を受けません。 代わりに、独自の運用前環境に、アプリの新しいバージョンが作成されます。 前に戻って GitHub で pull request を確認すると、[会話] タブに運用前バージョンへのリンクが表示されていることがわかります。

Azure Static Web Apps から別の URL にアプリを発行する方法を次の表に示します。 アプリは 1 つの URL に発行され、同じブランチへのプル要求は別の URL に発行されます。 これらの自動生成された URL は、運用アプリと pull request 用に Azure Static Web Apps によって提供されます。 必要に応じて、カスタム ドメインを運用アプリに割り当てることができます。

現在、 API ブランチで作業しています。 API ブランチからメイン ブランチにプル要求を行います。 メイン ブランチに対して pull request を作成すると、GitHub アクションによってアプリが実稼働前環境に発行されます。

ワークフローでアプリのビルドとデプロイが完了すると、GitHub ボットによって pull request にコメントが追加されます。 このコメントには、運用前環境の URL へのリンクが含まれています。 このリンクを選択すると、ステージされている変更を確認できます。

次に、pull request を作成し、アプリのステージング バージョンにアクセスします。