静的なWebアプリケーション-カスタムビルドと展開

claimsでマイクロソフトStatic Web Apps「ファーストクラスGituubとAzureデビルズ統合」にもかかわらず、1つはもう一方よりかなり使いやすいです.どのように多くの機能を簡単に見てみましょう我々はAzure devopsに付着して与えている
ギタブ
アド
パイプラインの構築/配備
自動的にパイプラインの定義を追加する
手動パイプライン設定が必要です
Azureポータルサポート
✓
✗
コード拡張
✓
✗
ステージング環境とプル要求
✓
✗
多くの機能が不足しているようです.しかし、これは私たちがそれについて何かできるかどうか質問をします?

我々がそうすることができるとわかります
ADOビルドパイプラインにさらに少し目を向けて、マイクロソフトがこのタスクon GitHubを発表したことに注目します.ビンゴ!
このプロセスはsingle scriptを実行しているようです.

...
docker run \
    -e INPUT_AZURE_STATIC_WEB_APPS_API_TOKEN="$SWA_API_TOKEN" \
    ...
    -v "$mount_dir:$workspace" \
    mcr.microsoft.com/appsvc/staticappsclient:stable \
    ./bin/staticsites/StaticSitesClient upload

正確にStaticSitesClientを行うのは不思議に包まれていますが、成功したビルド(using Oryx)では2つのZIPファイルを作成します.それから、それはBLOBストレージに両方をアップロードして、資産を拾うためにapp.zipエンドポイントのために要求を提出します.

それはどこでも動く
このイメージはADOまたはGiThubで実行する必要はありません!このコンテナをローカルで実行し、ソースコードをコミットせずに展開することもできます.必要なのは展開トークンです.

docker run -it --rm \
   -e INPUT_AZURE_STATIC_WEB_APPS_API_TOKEN=<your_deployment_token> 
   -e DEPLOYMENT_PROVIDER=DevOps \
   -e GITHUB_WORKSPACE="/working_dir"
   -e IS_PULL_REQUEST=true \
   -e BRANCH="TEST_BRANCH" \
   -e ENVIRONMENT_NAME="TESTENV" \
   -e PULL_REQUEST_TITLE="PR-TITLE" \
   -e INPUT_APP_LOCATION="." \
   -e INPUT_API_LOCATION="./api" \
   -v ${pwd}:/working_dir \
   mcr.microsoft.com/appsvc/staticappsclient:stable \
   ./bin/staticsites/StaticSitesClient upload

また、この展開がステージング環境をどのように作成したかについて、

言葉の注意
たとえそれがかなり良い少しのハックのようであるとしても-これは支持されません.また、「他の」ワークフローでリソースが作成された場合、ポータルはbug outで、正しく環境を表示することを拒否します.
ポータルサイト
アウェイCLI

結論
ダイビング静的なWebアプリケーションの展開に深く楽しいです.また、外部のソースコントロールが利用できない状況でも役に立つかもしれません.しかし、実際のプロダクションのワークロードに関しては、Githubフローを使用することをお勧めします.