Open jeffkreeftmeijer opened 14 years ago
I think that this is incompatible with using git for deployments. Unfortunately git pushes are simply not atomic. It's the one downside to using git and bothered me in heroku too. Does webbynode put up your maintenance page during pushes? Perhaps that's the middle ground here...
What do you need rollbacks for though? Can't you just push an older git tag to do a rollback?
Also, regarding apps going down. From my experience that never happened to me, simply because when you do a push to the server, it updates the source code, but that shouldn't matter cause everything is stored into memory is it not? Then after the push and post processes finish, passenger will restart the rails app, which, on the first request again stores the new code in memory.
Where exactly, in this process, does the app go down?
The real benefit of rollbacks as workflow items is reversing migrations etc, but you are right in that this is a fairly trivial issue
Well, I guess it depends on your git workflow. if you use the git-flow workflow then you have a few branches.
And a few others.
So consider the following scenario:
You've just tagged your application as version 1.0.1 and push it live. After it's pushed you realize something terrible happened, and you need to roll back to version 1.0.0.
git push origin 1.0.0
Done. Running 1.0.0
I doubt you really need a whole rollback system, since git can easily handle it, since it is a version control utility.
Or do you see any issues with this?
Note: the above git syntax might not be correct, it's more about the concept of pushing. Cause this would create a tag I believe. But maybe something along these lines:
git push webbynode +1.0.0:master
Not sure if that's correct or if it works as I haven't tested it yet. But if it does I'd personally prefer to work this way, maybe have some aliases to do it this way.
Wouldn't it be awesome to have symlinked folders (like Capistrano does) so your app doesn't go down while deploying and possibly adding rollbacks? :)