Ability to deploy using an Azure DevOps Release Pipeline

[stephajn]

Is your feature request related to a problem? Please describe.
I cannot use Azure Static Web Sites because I have an application I'd like to run but have different environments to run it with. I would like to be able to deploy an application into Azure Static Web Sites in a DevOps Release Pipeline as opposed to a build pipeline so that I can modify certain files based upon the environment I am deploying to.

Describe the solution you'd like
I would like to have a task available to me in a release pipeline instead of a build pipeline that allows me to unzip a previously built artifact, do any work on it like modifying any files as part of the release pipeline, and then finally a step that allows me to upload a folder of files into Azure Static Web Sites.

Describe alternatives you've considered
I tried using the Azure DevOps Build Pipeline option, but it will not work for me as I need to be able to deploy to multiple environments like DEV, STAGING, and PROD.

Additional context
It feels odd to me that a build pipeline should be deploying bits somewhere as opposed to a release pipeline. This feature seems to rely heavily on the idea that you are using GitHub as your source control repository. Well, we are using a Git repository on Azure DevOps instead, and that makes this feel like it is only half baked when I can't do what I'd like using DevOps as opposed to a Github Action.

[anthonychu]

We are working on a feature that'll allow you to deploy to named pre-production environments. Too early for an ETA but it should enable your scenario.

[AverageCakeSlice]

I'd like to second this. I want to use it in our enterprise environment with DevOps. As much as I like GitHub, I feel like it's not really used that much in serious business environments when compared to DevOps.

[Y90SMH]

Same scenario as @stephajn.
I've tried to use the task in an Azure DevOps Release Pipeline with a pre-built react app (and extracted it to $(System.DefaultWorkingDirectory)/app in the previous task) and log output is below (invalid characters are copied as-is from DevOps):

2021-08-06T18:17:42.5407717Z �[31mApp Directory Location: '/home/vsts/work/r1/a/app' is invalid. Could not detect this directory. Please verify your workflow reflects your repository structure.�[0m
2021-08-06T18:17:43.0097949Z �[37m�[0m
2021-08-06T18:17:43.0099559Z �[33mFor further information, please visit the Azure Static Web Apps documentation at https://docs.microsoft.com/en-us/azure/static-web-apps/�[0m
2021-08-06T18:17:43.0101398Z �[33mIf you believe this behavior is unexpected, please raise a GitHub issue at https://github.com/azure/static-web-apps/issues/�[0m

Task details:

2021-08-06T18:17:06.1764859Z Task         : Deploy Azure Static Web App
2021-08-06T18:17:06.1765212Z Description  : [PREVIEW] Build and deploy an Azure Static Web App
2021-08-06T18:17:06.1765488Z Version      : 0.187.1
2021-08-06T18:17:06.1765730Z Author       : Microsoft Corporation
2021-08-06T18:17:06.1766032Z Help         : https://aka.ms/swadocs

A task that's just for deployment would be great, I have the Skip app build toggled on too.

steps:
- task: AzureStaticWebApp@0
  displayName: Deploy
  inputs:
    app_location: '$(System.DefaultWorkingDirectory)/app'
    output_location: ./
    skip_app_build: true
    azure_static_web_apps_api_token: '$(deployment_token)'

[anthonychu]

We have an update coming to the DevOps task that will improve the experience for release pipelines. It should be deployed in the next few weeks. microsoft/azure-pipelines-tasks#14807

It's important to note that the app_location must be relative to the working folder. Currently, the task uses a working directory location that is incompatible release pipelines. microsoft/azure-pipelines-tasks#14807 will fix this.

[theo-albers]

We have the same use case: deploy from a release pipeline. Today we deploy to Azure BLOB storage, linked to a CDN. It would be nice to replace that part.

[remcohuijser]

Hi all,

We got this working quite ok for now. Not saying this is a long-term solution but it at least allowed us to use SWA in a way we like a bit more. Consider this inspiration 😎

So in our projects, we put these two steps in our azure-pipelines.yml. We do this after compiling the application. Please not that we leave the api as-is as the release pipeline always builds this and therefore needs source code.

- task: PublishBuildArtifacts@1
  inputs:
    PathtoPublish: '$(Build.SourcesDirectory)/dist'
    ArtifactName: 'dist'
    publishLocation: 'Container'
  displayName: 'Publish dist folder'

- task: PublishBuildArtifacts@1
  inputs:
    PathtoPublish: '$(Build.SourcesDirectory)/api'
    ArtifactName: 'api-dist'
    publishLocation: 'Container'
  displayName: 'Publish api dist folder'

We can then setup 2 release pipelines that both first download the artifacts created in the build pipeline (app and api). In a second step we run a bash script. This is quite a heavy beast but what it is basically doing is run the same docker image as the build pipeline step while providing configuration settings. As you can see below, with different settings you can create/update a staging slot or update your production slot. Please note that we did not find a way to detect closed pull requests so staging slots need to removed by hand.

RELEASE to PRODUCTION

docker run 
--entrypoint "/bin/staticsites/StaticSitesClient" 
--volume "$(System.DefaultWorkingDirectory)/$(Release.TriggeringArtifact.Alias)":/root/artifacts 
-e "IS_PULL_REQUEST=false" -e "BASE_BRANCH=$(Build.SourceBranchName)" 
-e "DEPLOYMENT_PROVIDER=DevOps" 
-e "REPOSITORY_URL=https://yournamehere@dev.azure.com/yournamehere/$(System.TeamProject)/_git/$(Build.Repository.Name)" 
mcr.microsoft.com/appsvc/staticappsclient@sha256:fc9db23777aea0ee404885f29ebc56305d016304b9ec07a3cd823d132016288b upload 
--skipAppBuild true 
--app /root/artifacts/dist 
--api /root/artifacts/api-dist 
--apiToken $(deploy_token)

RELEASE to STAGING

docker run 
--entrypoint "/bin/staticsites/StaticSitesClient"
--volume "$(System.DefaultWorkingDirectory)/$(Release.TriggeringArtifact.Alias)":/root/artifacts
-e "IS_PULL_REQUEST=true"
-e "BASE_BRANCH=$(Build.PullRequest.TargetBranchName)"
-e "DEPLOYMENT_PROVIDER=DevOps"
-e "REPOSITORY_URL=https://yournamehere@dev.azure.com/yournamehere/$(System.TeamProject)/_git/$(Build.Repository.Name)"
-e "PULL_REQUEST_ID=$(Build.PullRequest.Id)"
-e "PULL_REQUEST_TITLE=$(Build.PullRequest.Id)"
-e "HEAD_BRANCH=$(Build.PullRequest.SourceBranchName)"
mcr.microsoft.com/appsvc/staticappsclient@sha256:fc9db23777aea0ee404885f29ebc56305d016304b9ec07a3cd823d132016288b upload 
--skipAppBuild true 
--app /root/artifacts/dist 
--api /root/artifacts/api-dist 
--apiToken $(deploy_token)

[theo-albers]

We can then setup 2 release pipelines that both first download the artifacts created in the build pipeline (app and api). In a second step we run a bash script. This is quite a heavy beast but what it is basically doing is run the same docker image as the build pipeline step while providing configuration settings. As you can see below, with different settings you can create/update a staging slot or update your production slot. Please note that we did not find a way to detect closed pull requests so staging slots need to removed by hand.

RELEASE to PRODUCTION

docker run 
--entrypoint "/bin/staticsites/StaticSitesClient" 
--volume "$(System.DefaultWorkingDirectory)/$(Release.TriggeringArtifact.Alias)":/root/artifacts 
-e "IS_PULL_REQUEST=false" -e "BASE_BRANCH=$(Build.SourceBranchName)" 
-e "DEPLOYMENT_PROVIDER=DevOps" 
-e "REPOSITORY_URL=https://yournamehere@dev.azure.com/yournamehere/$(System.TeamProject)/_git/$(Build.Repository.Name)" 

We use Azure App Configuration to store our configuration externally. This allows us to use the AAC task https://marketplace.visualstudio.com/items?itemName=AzureAppConfiguration.azure-app-configuration-task to pull configuration into release pipeline variables. Next we use the variables in a File Transform task, https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/utility/file-transform?view=azure-devops, which updates the config file with the deployment settings. We have one build with artifacts and deploy via one release pipeline with different settings to 4 stages. This approach might replace your complex docker step.

We haven't used the docker deployment trick to deploy any artifact to Azure Static Websites, thanks for the pointer!

[slav-bukhal-gcm]

Any updates on this?

[anthonychu]

There are a couple of updates coming in the next few months to address this.

1. A skip_api_build flag that allows you to deploy build artifacts without the task rebuilding the app. Waiting for [AzureStaticWebAppV0] Add skip_api_build to Devops Task microsoft/azure-pipelines-tasks#15996. This is the tracking item: Allow skipping API build #343
2. Support for named pre-production environments. Work in progress, no date to share yet.

[simonaco]

We've just added support for named preview environments using Azure DevOps. Please give it a try and let us know if you have any feedback.

[johnnyreilly]

Thanks @simonaco! Will do!

[johnnyreilly]

Hey @simonaco

I've taken named preview environments for a spin. Seems to work - I've a bunch of questions:

• am I right in thinking that named preview environments can't be renamed once created?
• nothing cleans up a named preview environment I think? They live as long as your default branch lives?
• how many named environments could you have with an SWA? Based on my usage it seems like only one is possible - is that right?

The repo I've been testing it on this (the blog post mentioned in the README is old - so ignore that):

https://dev.azure.com/johnnyreilly/azure-static-web-apps/_git/azure-static-web-apps

You don't need to look at it; I just share for context

[johnnyreilly]

I've written up my experiences in this blog: https://blog.johnnyreilly.com/2022/05/07/static-web-apps-azure-devops-named-preview-environments

Do let me know if there's any issues with it!

[theo-albers]

We've just added support for named preview environments using Azure DevOps. Please give it a try and let us know if you have any feedback.

Why is this called "preview" and not "staging" like normal terminology in release pipelines and Azure resources?

[theo-albers]

We've just added support for named preview environments using Azure DevOps. Please give it a try and let us know if you have any feedback.

The feature can now pick up a build artifact in a release pipeline. In a typical scenario you still want some config to be modified in the static website build artifact. Staging might need different back end URI's for instance. As I mentioned earlier we use Azure App Configuration to rewrite specific keys in a config.json file we use in the build artifact. Unfortunately the AAC release task can't deal with JSON values to replace keys even though AAC supports JSON values at runtime together with Microsoft.Extensions.Configuration perfectly. It would be nice to team up with the AAC task owners and create a smooth experience to deploy a reconfigured build artifact.

[ngnlx]

I hope to see the update for this ticket soon.

[jtheisen]

Static website builders in particular often use dynamic content and do other shenanigans with external dependencies during build and so have a more fragile build process.

Hence separating build from release makes much more sense for static web apps than for regular ones.

I need a separation here more than I need one for my .NET apps.

[elninoisback]

This feature is much needed. Without this, the stages and approval flows have to be done in build pipelines (using yaml) and that doesn't scale if you have multiple build pipelines on multiple repos, working in tandem with a singular release pipeline.

[Reshmi-Sriram]

Static website builders in particular often use dynamic content and do other shenanigans with external dependencies during build and so have a more fragile build process.

Hence separating build from release makes much more sense for static web apps than for regular ones.

I need a separation here more than I need one for my .NET apps.

Hi @jtheisen ,
Could you please elaborate what exactly are you looking for here? As @anthonychu mentioned in this comment, we do have support for splitting build and release between different stages, thus letting you run the build once in the building stage, and then using skip_app_build:true in the other stages, sourcing it from the build stage. For more details you can check out the doc here.

[jtheisen]

Ok, I didn't look too closely at that.

Some minor question about that: AzureStaticWebApp@0 doesn't do only the build and I need to run the build with other tasks, right?

[Reshmi-Sriram]

Closing the issue.