How can one roll back to a previously deployed version

[hobpet]

What is the best practice to roll back to the previous version in case there is a problem with the released version. As there is no swap option and there is no access to the previously built artifacts, the traditional options does not seem to work here.

[Notaduck]

I might think you should look at your structure for your git repo. Just have a main and a develop and then checkout from develop to make feature/name, then check if develop works and create a PR fromdevelop -> main`.

If it then happens that there is an issue in main you can simply revert to an older commit and deploy that. I don't think there is any other way to do it. One other thing should be to have a testing suite running which would prevent the faulty code to be pushed to prod.

[mkarmark]

Hi @hobpet, to better understand your ask, are you basically asking for a way to send prod traffic to a staging site if a bug is detected in the prod site?

[hobpet]

Hi @mkarmark, Not really, what I would like to do is to roll back to the previous "known to be good" version on prod in case of a failure. This could be based on an automated or manual smoke test on prod after release. Actually all I want is to have safety for the release fast, fail fast, fix fast approach in smaller setups where there is no luxury of having enough prod infrastructure to manage the entire traffic if an update goes wrong on a node, so you cannot eliminate the traffic from the faulty node, but you need to roll back ASAP. BTW I think I have the solution to answer my own question, but I need to test it. Basically the idea is to use separate CI and CD pipelines and keep the built artifacts and repeat the CD from the "known to be good" version in case of failure.

[ryanbuening]

@hobpet I have the same question at the moment. What process did you end up using?

[exFalso]

Hmm we are currently switching to azure static web apps, and this is a major missing feature. To clarify, the static web app functionality should keep track of the previously deployed commits, and make it very easy to switch to a previously deployed version. Full re-deployment of a previous revision or a revert can take a long time depending on the build pipeline.

One workaround could be to create a proxy repository that tracks the build artifacts of the original repo, and have the actual repo push the build artifacts to this proxy. Then the deploy GH action can be almost a noop aside from the actual static-web-apps-deploy step. This would reduce re-deployment time in case of a rollback, but it's a very heavy-handed workaround of an issue that shouldn't exist in the first place.

[ghost]

This is definitely a deficiency of Azure Static apps. We presently use something like Octopus to handle our deployments to are current hosting where Octopus holds on to the build artifacts so we can quickly roll back, but we're hoping to drop Octopus and our present on-premises hosting and host in Azure Static web apps. Since the GH deploy action builds zip file artifacts that get pushed up to Azure we would hope that at least the previous zip files would be stored for a quick rollback without a full pipeline redeploy from our previous release.

[karex]

As the main logic of Static Web Apps is branch === deployment, what follows is that you want to modify your branch if you want to do a rollback.

There are multiple ways to do that in git.

• You can git revert <commit-id> individual commits.
• You can go back to a particular state in time without losing history, for example with: git reset --hard <commit-id> git reset --soft ORIG_HEAD git commit

But there are many other ways achieve such goals in git.

I was scratching my head too how to do a rollback of a SWA. But then I thought hey, it is in git where this has to be done. And this keeps things simple with keeping the branch === deployment logic. And simple is good.

But yeah, some hint in the documentation could be nice.

[Notaduck]

As the main logic of Static Web Apps is branch === deployment, what follows is that you want to modify your branch if you want to do a rollback.

There are multiple ways to do that in git.

• You can git revert <commit-id> individual commits.
• You can go back to a particular state in time without losing history, for example with: git reset --hard <commit-id> git reset --soft ORIG_HEAD git commit

But there are many other ways achieve such goals in git.

I was scratching my head too how to do a rollback of a SWA. But then I thought hey, it is in git where this has to be done. And this keeps things simple with keeping the branch === deployment logic. And simple is good.

But yeah, some hint in the documentation could be nice.

It would be beneficial for small companies that it could be done from azures web ui, I'm in a very small company where it could be a not so tech savy person who had to do the rollback. It is not an issue for me to use git but I would wish that it could be in the pipeline to do it through the web ui.

[exFalso]

A revert/reset also requires the build pipeline to run which may take some time, and in case of rollbacks time is of the essence. We can't just tell customers "sorry the website will be broken until the build pipeline finishes". This is all static files so a rollback should take an instant.

[ghost]

A revert/reset also requires the build pipeline to run which may take some time, and in case of rollbacks time is of the essence. We can't just tell customers "sorry the website will be broken until the build pipeline finishes". This is all static files so a rollback should take an instant.

That is our basic contention as well. I fully understand the concept of branch === deployment but when it comes to rollbacks we can't realistically tell our customers that we've degraded from a "rollback in 1 minute" timeframe (what got with Octopus) to a "rollback when pipeline completes" timeframe which can take up to 8 or 10 minutes. That's a huge difference to an end customer.

[bswitzer-emerge]

A revert/reset also requires the build pipeline to run which may take some time, and in case of rollbacks time is of the essence. We can't just tell customers "sorry the website will be broken until the build pipeline finishes". This is all static files so a rollback should take an instant.

Completely agree. Using git and waiting for a revert feels like it's way too slow as a process. Plus there can be additional side-effects with a git revert that are unpleasant and time-consuming to deal with. This seems like a very obviously missing feature to me.

[KasperAndersson]

Something like, https://vercel.com/docs/deployments/instant-rollback / https://docs.netlify.com/site-deploys/manage-deploys/#rollbacks, would be super helpful to have at a point where something breaks, and you don't want to wait for pipeline and make revert commits etc