#06: Предварительный просмотр статических веб-приложений

Добро пожаловать на Неделю 1, день 6 из #30DaysOfSWA!!!

Мы почти подошли к концу первой недели!!! 🎉

До сих пор мы узнали, как можно использовать возможности хостинга статических активов (Azure Static Web Apps) и бессерверного API (Azure Functions) для создания и развертывания веб-приложения масштабируемым и экономически эффективным способом. И мы научились настраивать и защищать наше Static Web App в соответствии с нашими потребностями. Так о чем еще нам нужно поговорить?

Варианты развертывания? Давайте сделаем это!!! До сих пор мы говорили о стандартном варианте: развертывание из производственной ветки, использование GitHub Actions для CI/CD. Но как нам быть с предварительным просмотром статического веб-приложения перед развертыванием на производстве? Давайте поговорим о предварительном просмотре SWA в pull request’ах, на непроизводственных ветках и в предварительно сконфигурированных именованных средах, которые делают наши рабочие процессы постановки более продуктивными.

Содержание

Что мы рассмотрим
Об авторе(ах)
Типы развертывания
Pull Requests
Ветви
Именованные окружения
Пользовательские домены
How-Tos: Смотрите!
Упражнение: Попробуйте!
Полезные ресурсы

Что мы рассмотрим

Какие типы развертывания поддерживает SWA?
Предварительный просмотр: в Pull Requests
Предварительный просмотр: в непроизводственных ветках
Предварительный просмотр: в именованных средах
Развертывание: в пользовательских доменах
Упражнение: Обзор PR с использованием возможности предварительного просмотра SWA

Об авторе(ах)

Михаил (Миша) Шапошников — инженер-программист в Microsoft, работающий, помимо прочего, с продуктом Azure Static Web Apps. Найти его можно по адресу mishapos на GitHub.

Типы развертывания

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

Azure Static Web Apps имеет встроенную поддержку четырех типов сред:

Production: Это конечная точка развертывания в реальном мире, которая индексируется поисковыми системами и связана с пользовательским доменом (если он настроен).
Pull Request (PR): Это временная среда, созданная для Pull Request, которая уничтожается, когда PR закрывается.
Филиал (Branch): Это среда, которую вы можете создать для непроизводственных ответвлений, со стабильным URL на время существования ответвления.
Именованная: Вышеперечисленные среды имеют URL-адреса, которые отражают их PR (номер) или ответвление (имя). Вы также можете настроить стабильную среду предварительного просмотра с фиксированным именем, связанным с некоторым контекстом развертывания (например, промежуточный релиз).

Производственные развертывания имеют URL-адреса типа <DEFAULT-HOSTNAME>-<NUMBER>.azurestaticapps.net, где DEFAULT-HOSTNAME уникально для каждого приложения.

В средах предварительного просмотра URL выглядит следующим образом: <DEFAULT_HOSTNAME>-<BRANCH_OR_ENVIRONMENT_NAME>.<LOCATION>.azurestaticapps.net, где LOCATION отражает регион развертывания, а BRANCH_OR_ENVIRONMENT_NAME может также принимать форму имени ветви, именованной среды или номера в случае запросов на выгрузку.

Давайте вкратце рассмотрим каждый из них.

Pull Requests

В настоящее время среды предварительного просмотра Pull Request доступны для проектов, размещенных на GitHub и настроенных на использование GitHub Actions с помощью Azure Static Web Apps:

Каждый PR в наблюдаемую ветку получает выделенную, но временную предпроизводственную среду постановки, которая разрушается после закрытия PR.
Используйте ее для проверки изменений, выполнения проверок на правильность и т. д.
Среда автоматически перестраивается и развертывается, если в ветку, связанную с активным PR, вносятся новые коммиты.
Если репозиторий GitHub является закрытым, то этапная среда является общедоступным событием, хотя по умолчанию URL-адрес не является легко обнаруживаемым (т.е. не индексируется поисковыми системами).

Узнайте, как предварительно просматривать Pull Requests в Azure Static Web Apps.

Ветви

Среды предварительного просмотра для веток будут иметь стабильные URL-адреса. Настройте их в соответствующих файлах рабочих процессов GitHub Actions или Azure Pipelines, как показано в этом примере.

Например, в контексте GitHub Actions это включает два шага:

установить свойство production_branch на ветку, которую вы хотите использовать в качестве источника для этого производственного развертывания.
перечислите все остальные ветки, для которых вы хотите создать окружения предварительного просмотра в trigger (Azure Pipelines) или push: branches (в GitHub Actions).

Вы можете использовать wildcare (** для GitHub Actions, * для Azure Pipelines), если хотите отслеживать все ветки для поддержки среды предварительного просмотра.

Вот пример конфигурационного файла GitHub Actions — производственная среда создается из основной ветки, а для других перечисленных веток (dev и staging) создаются отдельные среды предварительного просмотра.

Узнайте, как создавать среды предварительного просмотра ветвей в Azure Static Web Apps.

name: Azure Static Web Apps CI/CD

on:
  push:
    branches:
      - main
      - dev
      - staging
  pull_request:
    types: [opened, synchronize, reopened, closed]
    branches:
      - main

jobs:
  build_and_deploy_job:
    ...
    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:
          ...
          production_branch: "main"

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

Именованные окружения

Иногда требуется непроизводственная среда предварительного просмотра, которая находится на стабильном URL (не привязана к определенному номеру PR или имени ветки) и перестраивается при фиксации всех отслеживаемых веток в конфигурационном файле.

Как и в случае с ветками, для этого необходимо вручную внести изменения в файл конфигурации по умолчанию (GitHub Actions или Azure Pipelines), как показано в этом примере.

В случае с GitHub Actions шаги следующие:

Установите свойство deployment_environment (в соответствующем задании сборки) в качестве имени, которое вы хотите использовать для этой среды предварительного просмотра.
Перечислите ветки, которые вы хотите связать с этим именованным окружением в push: branches — коммиты в них приведут к пересборке/развертыванию в это окружение.

Вот пример конфигурационного файла GitHub Actions — он устанавливает именованную среду под названием release, которая обновляется при внесении изменений в любую ветку (что отражается подстановочным знаком **) и развертывается на сайте с URL-адресом типа <DEFAULT_HOST_NAME>-release.<LOCATION>.azurestaticapps.net.

Узнайте об именованных средах предварительного просмотра в Azure Static Web Apps

name: Azure Static Web Apps CI/CD

on:
  push:
    branches:
      - "**"
  pull_request:
    types: [opened, synchronize, reopened, closed]
    branches:
      - main

jobs:
  build_and_deploy_job:
    ...
    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:
          ...
          deployment_environment: "release"

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

Пользовательские домены

Вы могли заметить, что URL-адреса развертывания по умолчанию — в виде XXX.azurestaticapps.net для производственных сред или XXX.<LOCATION>.azurestaticapps.net для сред предварительного просмотра — не совсем удобны для использования и запоминания.

Добавление пользовательского домена помогает. Azure Static Apps упрощает эту задачу, предлагая возможность настройки поддоменов и apex-домена! Здесь, учитывая домен типа www.azure.com, azure.com — это вершинный домен, а www — соответствующий поддомен.

Как же их настроить? У вас есть два варианта:

Использовать внешнего DNS-провайдера (если ваш регистратор домена поддерживает его).
Использовать Azure DNS (для управления DNS домена, даже если он приобретен в другом месте).

Чтобы сделать эту статью короткой, мы не будем подробно описывать каждый из этих вариантов. Вместо этого ознакомьтесь с этими ссылками в зависимости от того, в каком направлении вы хотите двигаться:

Установка домена Apex — с Azure DNS | с внешним провайдером
Установка поддомена — с Azure DNS | с внешним провайдером

How-Tos: Смотрите!

Предпочитаете видео-инструкцию для понимания процесса? Мы поможем вам с помощью серии «Советы и подсказки Azure: Серия «Статические веб-приложения». Посмотрите это видео, чтобы понять, как настроить пользовательский домен для вашего статического веб-приложения!

Упражнение: Попробуйте!

Pull Requests критически важны для продуктивного проекта с открытым исходным кодом или с несколькими участниками, поэтому важно знать, как Azure Static Apps работает в создании предпроизводственных сред для проверки изменений, предложенных в pull-request, перед их объединением для развертывания в производстве.

Получите практический опыт в этом процессе, выполнив это руководство на существующем проекте Azure Static Web Apps.

В настоящее время поэтапная предпроизводственная среда для Pull Requests доступна только для развертывания GitHub Actions — поэтому убедитесь, что вы выбрали проект SWA на GitHub, в котором уже настроены рабочие процессы по умолчанию.

Полезные ресурсы

Среды предварительного просмотра в Azure Static Web Apps
Среды предварительного просмотра Pull-Request
Среды предварительного просмотра ветвей
Именованные среды предварительного просмотра
Серия видеороликов: Советы и рекомендации Azure — статические веб-приложения
О пользовательских доменах