Les preview environments sur les PR

Cet article fait partie de la série Azure Static Web Apps avec Blazor.

Un exemple complet et fonctionnel est disponible ici : mongeon/code-examples · azure-swa-blazor/06-preview-environments.

C’est une des features de SWA que je trouve les plus sous-estimées. Chaque fois que vous ouvrez une pull request contre votre branche de production, Azure crée automatiquement un environnement temporaire avec sa propre URL. Le reviewer peut cliquer sur le lien, tester les changements en live, et approuver ou refuser la PR. Quand la PR est fermée, l’environnement est détruit automatiquement.

Plus besoin de partager un serveur de staging “toujours un peu en retard”, plus de “ça marche sur ma machine”. Chaque PR a son propre environnement isolé.

Comment ça marche?

Le workflow GitHub Actions généré par SWA supporte déjà les preview environments. Regardez la section on de votre workflow :

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

Quand une PR est ouverte contre main, le workflow se déclenche et déploie dans un environnement temporaire. L’URL suit le format :

https://<votre-hostname>-<numéro-de-pr>.<région>.azurestaticapps.net

Par exemple, votre première PR va être disponible sur quelque chose comme https://lively-moss-123456-1.eastus2.azurestaticapps.net.

Le workflow contient aussi un job close_pull_request_job qui nettoie l’environnement quand la PR est fermée ou mergée :

close_pull_request_job:
  if: github.event_name == 'pull_request' && github.event.action == 'closed'
  runs-on: ubuntu-latest
  name: Close Pull Request
  steps:
    - name: Close Pull Request
      uses: Azure/static-web-apps-deploy@v1
      with:
        azure_static_web_apps_api_token: ${{ secrets.AZURE_STATIC_WEB_APPS_API_TOKEN }}
        action: "close"

Vous n’avez rien à configurer. Ça fonctionne dès que le workflow est en place.

Le bot GitHub

Après le déploiement, un bot Azure Static Web Apps ajoute un commentaire dans votre PR avec le lien vers l’environnement de preview. Le reviewer n’a qu’à cliquer. Si vous poussez de nouveaux commits sur la même branche, l’environnement est mis à jour automatiquement et le lien reste le même.

Les environments de branche

Au-delà des PR, vous pouvez aussi créer des environments pour des branches spécifiques. C’est utile si vous avez une branche dev ou staging que vous voulez rendre accessible en permanence.

Ajoutez les branches dans la section push du workflow :

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

L’URL de l’environment de branche est stable et inclut le nom de la branche :

https://<votre-hostname>-dev.<région>.azurestaticapps.net

Contrairement aux environments de PR, les environments de branche persistent tant que la branche existe. Vous pouvez les supprimer manuellement dans le portail Azure sous l’onglet Environments de votre Static Web App.

Les named environments

Si vous voulez un environnement de staging qui ne dépend pas d’un nom de branche, vous pouvez utiliser les named environments. Ajoutez la propriété deployment_environment dans votre workflow :

- 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 }}
    repo_token: ${{ secrets.GITHUB_TOKEN }}
    action: "upload"
    app_location: "."
    api_location: "Api"
    output_location: "wwwroot"

L’URL sera https://<votre-hostname>-staging.<région>.azurestaticapps.net. Les named environments persistent jusqu’à ce que vous les supprimiez explicitement.

Les variables d’environnement par environment

Votre preview environment va probablement avoir besoin de variables différentes de la production. Par exemple, pointer vers une base de données de test au lieu de la production.

Dans le portail Azure, sous Static Web Apps > Environment variables, vous pouvez configurer des variables par environnement. Chaque preview environment (PR, branche ou nommé) a ses propres settings.

C’est aussi possible via le CLI Azure :

az staticwebapp appsettings set \
  --name my-blazor-app \
  --resource-group my-rg \
  --environment-name "staging" \
  --setting-names "DATABASE_CONNECTION_STRING=ma-connection-string-de-staging"

Les limites à connaître

Le nombre d’environments de preview dépend de votre tier. Le tier gratuit permet 3 environments en plus de la production. Le tier Standard en permet 10.

Les preview environments sont accessibles publiquement par leur URL, même si votre repo GitHub est privé. L’URL n’est pas indexée par les moteurs de recherche, mais n’importe qui avec le lien peut y accéder. Si c’est un problème, vous pouvez activer la protection par mot de passe dans le portail Azure sous Configuration > General settings > Protect staging environments.

Les preview environments ne supportent pas les domaines personnalisés. Ils utilisent toujours le sous-domaine azurestaticapps.net.

Dernière chose : les linked backends (qu’on a vus dans l’article 3) ne fonctionnent pas avec les preview environments de PR. Les managed functions, par contre, sont déployées dans chaque preview environment.

Articles de la série

C’est quoi une Azure Static Web App?
Le fichier staticwebapp.config.json
Brancher une API Azure Functions
L’authentification intégrée de SWA
Développer localement avec le CLI swa
Les preview environments sur les PR (Cet article)

Bon déploiement, et bonne révision de PR.

Cet article a été rédigé avec l’aide de l’IA et révisé par moi.