search

Azure / static-web-apps

Azure Static Web Apps. For bugs and feature requests, please create an issue in this repo. For community discussions, latest updates, kindly refer to the Discussions Tab. To know what's new in Static Web Apps, visit https://aka.ms/swa/ThisMonth
https://aka.ms/swa
MIT License
330 stars 56 forks source link

Review Pull Requests + Environments + Azure DevOps #497

Open seangwright opened 3 years ago

seangwright commented 3 years ago

Is your feature request related to a problem? Please describe. Reviewing pull requests in pre-production environments is only supported via GitHub actions today.

Describe the solution you'd like It would be awesome to support this (Static Web App Environments + Pull Requests) in Azure DevOps now that DevOps is a supported repository source for Static Web Apps.

Describe alternatives you've considered The current alternative is to create an Azure Static Web App per environment and use multi-stage build pipelines to deploy changes through environments.

Additional context

Currently, only GitHub Actions deployments support pre-production environments.

See: https://docs.microsoft.com/en-us/azure/static-web-apps/review-publish-pull-requests

anthonychu commented 3 years ago

For the pull request based staging environments like GitHub, we currently can’t support them in Azure DevOps due to some differences between the platforms.

You mentioned using multiple stages in a pipeline to deploy to different Static Web Apps. Would it be useful to be able to set up the same pipeline, but instead of deploying to separate Static Web Apps, you can deploy to different environments in the same static web app? For example, you could create dev, qa, staging environments in a static web app, and you can set up a pipeline to deploy to each of those environments, then to production. We are currently evaluating whether we should support something like this.

seangwright commented 3 years ago

@anthonychu That would be fine too and very similar to the deployment slots pattern we use with Azure App Service apps.

Would that be a configuration parameter on the AzureStaticWebApp task or different deployment tokens per environment?

We are looking at using NetlifyCMS and while it does 'work' many of the cool features supported by using GitHub and Netlify don't seem to be possible with DevOps/Azure.

foconnor-DS commented 3 years ago

I just spent too long trying to figure out how to 'add' environments to ASWA. Coming from App Services Land, this was very straight forward. I want to add a Dev, QA and keep my Production slot/environment on ASWA. Then I'd like to configure my pipeline to push based on typical review/approve stuff built into DevOps. Right now, I'm having to do what OP does, and stand-up distinct ASWA entities to create test environments.

One of the most important edge conditions for me, is that the API functions bindings should support slot binding. So my Azure function host has three slots ( dev, qa, production ). I'd like to bind my ASWA to a specific API slot. My QA-ASWA would be bound to my QA-Azure function host. The interface does not permit this currently. I plan to open a separate ticket for this.

michalorac commented 2 years ago

Is something new with Environments support? We would like to continue using AzureDevOps Environments with approvals for different stages.

simonaco commented 2 years ago

We've recently added support for:

  1. named preview environments in Azure DevOps
  2. A skip_api_build flag that allows you to deploy build artifacts without the task rebuilding the app

Please give it a try and let us know if you have any feedback.

SchulteMarkus commented 2 years ago

We've recently added support for:

  1. named preview environments in Azure DevOps
  2. A skip_api_build flag that allows you to deploy build artifacts without the task rebuilding the app

Please give it a try and let us know if you have any feedback.

Well. Am I right, that

  - task: AzureStaticWebApp@0
    inputs:
      ...
      deployment_environment: "release"

is a fixed value "release" for deployment_environment?! Every branch (well, could depend on a condition) will be deployed to the same "release" domain?

This issue is about is something like 

- task: AzureStaticWebApp@0
  inputs:
    ...
    deployment_environment: $(Build.SourceBranchName) <---

I have tested this, does not work (as intended).

bkarstaedt commented 2 years ago

This is what my approach for the pull request based staging environments for Azure DevOps / AZDO would be (testing it soon) :

  1. Create branch preview environments for feature/* (e.g. feature/ticket-123) branches:
pr:
  branches:
    include:
    - features/*

...

- task: AzureStaticWebApp@0
    inputs:
      # deployments from other branches will create a "preview environment"
      # see https://docs.microsoft.com/en-us/azure/static-web-apps/branch-environments
      production_branch: main
      ...
  1. After PR is merged into main branch delete the "preview environment" (here from branch feature/ticket-123) via az call:
az staticwebapp environment delete --name my-static-app --environment-name ticket-123 --subscription my-sub

The environment name ticket-123 might be extracted from the commit message (I don't know a better way here currently).

⚠️ If I have a running version of this concept I will update my comment here.

feedm3 commented 2 years ago

We also had the need for a Netlify-like experience with Azure DevOps and SWA:

I expected this feature set out-of-the-box from SWA, but it seems it's missing some pieces yet. We still figured out a way to solve this problem with 2 custom pipelines:

  1. The first pipeline builds and deploys the app and posts a comment to the assigned PR with the link to the deployment.
  2. The second pipeline cleans up all unused deployments. We do this by fetching all open PRs and comparing it against deployments in SWA. Every deployment that doesn't have a PR will be deleted.

Feel free to check out my repo with all scripts and pipelines combined. The solution has some drawbacks documented in the README. They shouldn't matter that much if everyone is aware of it: https://github.com/feedm3/learning-azure-swa-devops/

There are also some open Issues that could improve working with SWA a lot and may lower the need for a custom solution like mine: