Azure should keep past deployments and should quickly allow you to roll back
Azure should keep past deployments, both the record of the deployment and the package, and should quickly allow you to roll back to old deployments via the online management portal.
When deploying a new version of an app to staging or production, Azure should automatically snapshot the currently-running version and save it in blob storage, along with a version number and time stamp. Then, if things go horribly wrong, you could easily roll back to a previous known working snapshot.
This needs to be super-simple: A check-box option to decide whether we want snapshotting, some options for how many snapshots and how far back they should go.
Restoring a snapshot should be as simple as clicking on the version hyperlink.
Good idea. In the mean time, contact Azure support if you need to retrieve an old deployment.
vishal Tiwari commented
I have seen all the comment but there is no one solution for this problem anybody can suggest me how can we get the previous deloyement package form the azure.
vishal Tiwari commented
how it is possible to roll back to old deployments via the online management portal.
Phil Yardley commented
I can't see how deploying from stored package would be too much quicker than getting a tagged version from your source control, building and deploying ? (you are using source control aren't you? :) ). If its taken a week for someone to notice a "major" issue with the app - it's probably not a big issue if it takes 5 extra minutes to roll back?
you could have a separate area in source control where you store your deployment packages? that would save getting tagged versions and building
Christen Thompson commented
I would enjoy the ability to simply right click on an instance and roll it back to a previous deployment.
This sounds like it is specifically for cases where you are using the website or visual studio to do your deployments. If it were implemented I think it needs to be specifically for those tools or provide a way to opt out for companies that have automated deployments setup via powershell or the various SDK libraries and prefer to manage their own versioning (especially if there is additional storage cost involved to store the prior deployment packages).
James Reategui commented
I have just lived through what JNK has explained. A solution that would easily solve that problem would help us want to continue using Azure.
The only drama you have with this is if your deployment includes schema changes of the breaking kind that rolling back will cause all sorts of loss of new data you have been accumulating.
Azure can allow you to do a VIP Swap and you leave the one you swapped out live and can swap back at any time, though you do pay for an entire new instance.
James Newton-King commented
I don't see what DR has to do with this and you haven't described what backup would do so how can I say?
I'll give you a scenario:
I have a happily running production deployment. After testing first in staging I move a new deployment into production and delete the old one.
A week later an urgent bug is found in the new deployment. I want a simple and quick way to roll back to the old version. A simple way to do this would be if Azure kept a history of past deployments and the packages. Then I could simply go back into the online management portal and roll back to an old version as simply as I can currently switch production/staging instances.