GitHubでコードを管理・デプロイする

1. コードをGitHubへ登録

ローカルGitはmasterブランチ、GitHubはmainブランチなので、ローカルGitをmasterからmainに変更しておきます。

しなくてもいいけど、pushするとき、毎回「git push -u origin master:main」と長くなるので。

git branch -M main

ローカルGitのブランチがmainであることを確認。

次にGitHubのmainブランチに、ローカルGitのmainブランチをpush。

git remote add origin https://github.com/<ユーザー名>/<リポジトリ名>.git

git push -u origin main

実行したらこんな画面がポップアップで表示される。

緑ボタンを押す。

で、pushするとき、GitHubにReadmeなどファイルがあると競合するので、先にpullしておかないといけない。

git pull origin main --allow-unrelated-histories

終わったらpush

するとGitHub側にソースコードがpushされる。

2. Azure PortalでGitHub連携

AzureポータルでWeb Appsのデプロイセンターに移動する。

まずはローカルGitを切断。

ソースを「GitHub」にする

GitHubアカウントの情報を入れる

認証の設定では、ユーザー割り当てマネージドIDを指定します。

自動的に新規作成してくれますが、自分で名前を決めたいときは、事前に作成して指定します。

この場合、Web Apps の RBAC（IAM） で、この ID に対し「Web サイト共同作成者」権限を付与しておきます。（権限がないとエラーが出ます）

終わったら保存します。

するとfeatureブランチにワークフローフォルダが作られ、YAMLファイルが生成されます。

アプリのコードを修正し、pushします。

ローカルGitは「main」なので、GitHubと同じ「feature/github-actions」を作っておきます。

git checkout -b feature/github-actions

GitHub側はYAMLが追加されているので、ローカルGitも同じ環境にするためプルしておきます。

git pull origin feature/github-actions --allow-unrelated-histories

YAMLファイルが取得できたのがわかりますね。

コードを修正したらコミットしてpushします。

git add .
git commit -m "GitHub Actions test"
git push -u origin feature/github-actions

pushすると、YAMLに書いてある通りアプリをデプロイしてくれますが、ここでデプロイエラーが出ました。

赤字の部分をコピーしておきます。

次にユーザー割り当てIDのフェデレーション資格情報を開きます。

既定で１個できていますが、これを削除して、「＋資格情報の追加」をクリック。

フェデレーション資格情報のシナリオは「その他」。

発行者 URL：https://token.actions.githubusercontent.com

サブジェクト識別子：コピーした（repo:＜GitHubアカウント＞@274690514/MS-Server@1316974054:ref:refs/heads/feature/github-actions）

名前：任意

これでpushしたらエラーなくデプロイできるようになります。

ためしに画面の文字を追加しました。pushしただけでデプロイされました。

３．ステージングスロットにデプロイ

アプリを修正したとしても、いきなり本番スロットにデプロイするのは怖いので、ステージングスロットにデプロイして動作確認し、問題なければスワップしてステージングスロットと本番スロットを切り替える運用が一般的です。

最初に「デプロイスロット」からステージングスロットを作ります。

Clone setting from: は「ykweb01」を選択。これでデフォルトで存在する方が本番スロットになります。

次にステージングスロットの「デプロイセンター」に移動します。

GitHub連携の設定は引き継がれないので、本番スロットと同じ設定をいれます。

ワークフローオプションは「ワークフローの追加」を選びます。

これで本番用とステージング用のYAMLファイルができます。

YAMLファイルを見ると、ステージングスロットにデプロイするようになっていることが分かります。

ではステージングスロットにプッシュしてみます。

このままだと、本番スロット用に作成したYAMLもあるので、pushすると本番スロットもデプロイされちゃいます。

そのため本番スロットのYAMLのブランチを「main」にしておきます。

こうすると、mainブランチに対してpushしたときは本番スロット、featureスロットに対してpushしたときはステージングスロットにデプロイされるようになります。

ステージングスロット側のURLを開くと、画面が変わっています。

本番スロットのURLは変わっていません。

４．スロットスワップ

ステージングスロットにデプロイしたら、スワップします。

本番スロットのURLにアクセスすると、ステージングスロットにデプロイした内容が表示されます。

逆にステージングスロットのURLをアクセスすると、本番スロットの内容が表示されます。

ちなみにスロットスワップしてスワッピングされるのは「アプリ」と「スロットスワップの設定がオフの環境変数」だけです。

５．補足：GitHub連携はAzureポータルで設定しなくてもいい

手順３で、AzureポータルでGitHub連携を行う手順を記載しましたが、実はこれはGitHub ActionsでデプロイするYAMLファイルをAzure側で自動生成してくれるだけで、この手順をしなくても手動で設定することも可能です。つまりデプロイセンターでソースをGitHubにしなくてもいい、ということです。

1. ユーザー割り当て ID を作成
2. App Service に権限付与
3. フェデレーション資格情報を作成
   • 発行者：https://token.actions.githubusercontent.com
   • サブジェクト対象者：repo:＜GitHubアカウント＞/＜リポジトリ＞:ref:refs/heads/＜ブランチ＞
   • 対象ユーザー：api://AzureADTokenExchange
4. GitHub Secret を作成　→　下記をGitHubのシークレット値に登録
   • AZURE_CLIENT_ID：ユーザー割り当てIDのクライアントID
   • AZURE_TENANT_ID：AzureテナントID
   • AZURE_SUBSCRIPTION_ID：AzureサブスクリプションID
5. Workflow を作成
   • ファイルを作る → .github/workflows/deploy.yml
6. Push したら自動デプロイされる

ymlは以下の通り。ステージングスロットにデプロイするようにしてます。

name: Deploy to Staging

on:
  push:
    branches:
      - feature/github-actions

permissions:
  id-token: write
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Login to Azure
        uses: azure/login@v2
        with:
          client-id: ${{ secrets.AZURE_CLIENT_ID }}
          tenant-id: ${{ secrets.AZURE_TENANT_ID }}
          subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

      - name: Deploy to Web App
        uses: azure/webapps-deploy@v3
        with:
          app-name: 'ykweb01'
          slot-name: 'staging'
          package: .