Использование Azure Static Web Apps из коробки в ваших сложных конвейерах

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

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

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

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

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

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

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

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

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

Из коробки

Давайте начнем с задания рабочего процесса Azure Static Web App GitHub из болота:

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: https://aka.ms/swaworkflowconfig
        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 ######
Войти в полноэкранный режим Выйти из полноэкранного режима

Что же это делает?

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

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

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

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

Давайте настроим это действие так, чтобы оно только загружало приложение в 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: https://aka.ms/swaworkflowconfig
    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 ######
Вход в полноэкранный режим Выход из полноэкранного режима

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

  • Местоположение приложения изменилось на «Client/wwwroot».
  • Появились 2 новые опции
    • skip_app_build
    • skip_api_build

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

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

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

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

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

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

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

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

А мы знаем, и в обход Action нам нужно вручную указать SWA, что именно мы делаем.

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

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

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

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

Заключение

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

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

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

Просмотрите MS Docs для получения дополнительной информации о том, как настроить рабочий процесс Static Web App.

Фотография на обложке от Lucas Santos на Unsplash

Оцените статью
devanswers.ru
Добавить комментарий