This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(163.2, 39%, 25%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EKP%3C/text%3E%3C/svg%3E)
We are migrating from Azure app service to Azure static web application. We created a build pipeline for this which is also currently deploying the application. We were able to create a separate build and release pipeline for Azure app service but not sure how to separate this for Azure static web app.
Appreciate some inputs on this.
Hi, @Koteswara Pentakota
Where are you currently trying to run the pipeline?
Azure dev ops. We created a project and pipelines are created in static web app project. We could create only one pipeline which is currently building and deploying the static web app. We want to separate the build and release pipelines like how we did this for app service.
Hi @Koteswara Pentakota ,
When you say separate, I'm assuming you mean being able to run your App Service pipeline and Static Web App pipeline independently of each other. Other than setting the trigger property in Azure Pipelines; on in GitHub Actions, I don't believe there's any way to separate the two. Reason being your yaml is part of your repo. The only option I can think of is using the Azure Pipelines Classic Editor, basically using a Build Agent to pull down your code, build it, and publish the assets. Now I don't believe you can use Static Web Apps for this, but you can definitely switch your App Service to this sort of deployment.
No @Ryan Hill . When i say separate we have a build pipeline and a release pipeline for app services. Build pipeline can build the application and keep the artefact ready. This can be a continuous integration. While the release pipeline is to deploy the artefact into the app service container.
We were able to create both pipelines in app services. While using static web apps we were given a yaml file which is doing the build and deployment in the same pipeline as there is a token associated with azure static web app. So we are looking for ways to separate these pipelines one to create only builds but the other will help deploy the build. If we have only pipeline building it would be error prone when CI/CD is enabled as every build which is not meant for deployement can be deployed.
Thanks for the clarification @Koteswara Pentakota . Static Web Apps isn't designed for this scenario. The offering is to reduce the complexities of building and releasing code that doesn't require server-side processing. There isn't a release pipeline because the build output is the content hosted by the Static Web App. If you take a look at AzureStaticWebAppV0, you'll notice the task just sets environment variables for the serverless hosting environment to retrieve the assets.
So does this mean we should not use a CI/CD for Azure static web apps? Do we need to use only for build deployment purpose manually?
You're still using CI/CD @Koteswara Pentakota , but the deployment step is implied. For instance, if we're talking about an Angular App, you set the build_output in pipeline to /dist and the platform knows to pull these files for hosting. You're not "building" the site in the traditional sense. I use that term loosely because you can still configure build commands. But since the site is already static, you're instructing the pipeline what files are to be hosted, per se.
I believe preview environments could address your concerns for preventing code errors. This will allow you view the site changes through a temporary URL that's based on either PR or branch before committing changes to your main (or release) trunk.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(224.00000000000003, 43%, 31%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EJT%3C/text%3E%3C/svg%3E)
It would still make sense to have the two separated, as a build can depend on external servers to serve assets whereas the release itself should not depend on that.
Hence, having those separate provides a greater peace of mind to be able to revert to a previous release - you don't have to depend on that older version still being able to build the way it did before.