Ранее в этом году на AzureLive Я выступил с докладом об аутентификации в статических веб-приложениях Azure (SWA). Перед своим выступлением я разговаривал с кем-то, кто думал, что SWA — это весело, но не то, что можно использовать всерьез. Самая большая жалоба у них была: процесс сборки.

По умолчанию вы получаете настроенный для вас поток CI/CD. Каждое нажатие на вашу магистральную ветку будет запускать сборку и развертывание. И для этого не нужно ничего делать. Потрясающий!

Но хотя это работает для простых приложений и помогает людям начать работу, если у вас есть большое и сложное приложение, а ваш SWA является лишь небольшой его частью, то как вы можете запустить все необходимые процессы?

Под этим они подразумевали такие вещи, как:

  • Как вы запускаете модульные тесты?
  • Как обеспечить развертывание одного и того же кода при развертывании в нескольких средах?
  • Как вы контролируете как код построен, когда все это заключено в волшебное действие GitHub?

Для первого из них есть чит, если вы все еще запускаете небольшое приложение — просто соберите решение и запустите свои модульные тесты. до вы используете действие GitHub. Это работает, это то, что я делал в то время для своего личного сайта. Но это также увеличивает время сборки в процессе развертывания, которого я бы предпочел не ждать, если собираю что-то серьезное.

Два других… Ну, SWA поставляются из коробки с поддержкой промежуточных сред — но опять же, хотя это действительно хорошо работает для небольших приложений, я вижу, что приложение, которое вписывается в более крупную экосистему, будет немного сложнее. .

И последнее… Это закрытая система. Вы предоставляете код. Действие GitHub выясняет, как его построить. Вот и все.

Кажется, они были правы. Но я не собирался так просто сдаваться. Итак… Вызов принят!


Из коробки

Начнем с необычного задания рабочего процесса GitHub для статического веб-приложения Azure.

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_AMBITIOUS_GROUND_011396E03 }}
        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: 
        app_location: "Client" # App source code path
        api_location: "Api" # Api source code path - optional
        output_location: "wwwroot" # Built app content directory - optional
        ###### End of Repository/Build Configurations ######
Войти в полноэкранный режим

Выйти из полноэкранного режима

Итак, что это делает?

  • Он срабатывает, когда происходит нажатие на ветку, запускающую рабочий процесс.
  • Он проверяет репозиторий
  • Он использует Azure/static-web-apps-deploy@v1 действие, чтобы сделать следующее
    • Создайте приложение, используя код в app_location каталог
    • Создает приложение-функция Azure, используя код в api_location каталог
    • Развертывает приложение в Статическом веб-приложении Azure.

Как это происходит, мы не знаем и не заботимся — это просто происходит. И в 99,9% случаев это работает, и нам никогда не приходится об этом думать.

Однако, если вы хотите сделать что-то более продвинутое, вы можете это сделать. Мы можем запретить действию некоторые из этих вещей. Для этого нам нужно взглянуть на некоторые опции, которые не существуют из коробки.


Настройка действия

Давайте настроим это действие так, чтобы приложение загружалось только в SWA.

- 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_YELLO_RIVER_13413E103 }}
    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 you app requirements. ######
    # For more information regarding Static Web App workflow configurations, please visit: 
    app_location: "ClientDist/wwwroot" # App source code path
    api_location: "ApiDist" # Api source code path - optional
    skip_app_build: true
    skip_api_build: true
    ###### End of Repository/Build Configurations ######
Войти в полноэкранный режим

Выйти из полноэкранного режима

На первый взгляд это очень похоже, но есть некоторые отличия:

  • Расположение приложения изменилось на «Клиент/wwwroot».
  • Есть 2 новых варианта
    • skip_app_build
    • skip_api_build

Эти 2 варианта говорят сами за себя. Если вы установите их на true, то действие пропустит сборку приложения. Если вы установите их на falseто действие создаст приложение.

Таким образом, мы больше не позволяем Action создавать приложение. Мы просто указываем место, где действие может завладеть построенным приложением. Это может быть приложение, которое было создано и протестировано на предыдущих шагах.

Или это может быть приложение, созданное в предыдущем задании, что позволяет нам развертывать одно и то же скомпилированное приложение в нескольких средах.


Использование этого в реальной жизни

Итак… Вы берете то, что я сказал, и используете это в своем собственном приложении.

Когда вы сделаете это, первое, что вы заметите, это то, что ваши вызовы API, если вы их используете, не будут работать.

Упс. Оказывается, это действие делает больше, чем просто сборка и развертывание. Он также анализирует исходный код и соответствующим образом настраивает SWA.

Поскольку он больше не создает API, он не может этого сделать. Это развертывание .NET? NodeJS? Кто знает.

Что ж, мы делаем, и, минуя действие, нам нужно вручную сообщить SWA, что мы делаем.

Как и в большинстве случаев конфигурации SWA, это делается в staticwebapp.config.json файл.

В приведенном ниже фрагменте я настроил SWA для запуска .NET 6.0 в качестве среды выполнения API:

  "platform": {
    "apiRuntime": "dotnet:6.0"
  },
Войти в полноэкранный режим

Выйти из полноэкранного режима

Установив это в верхней части файла конфигурации, наш API должен снова начать работать после его развертывания 😅


Вывод

Итак… SWA отлично подходят для новичков, которым просто нужна простота развертывания «из коробки», не беспокоясь о как это на самом деле происходит и для разработчиков с более сложными рабочими процессами, которым нужен полный контроль.

Таким образом, мы можем включать SWA в более крупные и сложные системы, где нам нужен полный контроль, чтобы гарантировать, что наши приложения ведут себя должным образом.

Кроме того… По моему опыту, это также сократило время, затрачиваемое на сборку и развертывание приложения (по крайней мере, в моем рабочем процессе Blazor/.NET Function)

Оформить заказ Документы MS для получения дополнительной информации о том, как настроить рабочий процесс статического веб-приложения.

Фото на обложке Лукас Сантос на Скрыть