Do your examples support zero downtime deployment and zero downtime rollback? If so, could you please point to the relevant sections? I couldn't figure it out from the READMEs.
> Do your examples support zero downtime deployment and zero downtime rollback?
Those examples are for running your app, not deploying it.
Zero downtime is also a loaded term.
MRSK isn't zero downtime in a way that's commonly described as zero downtime. MRSK uses Traefik's built in functionality to queue requests so if your back-end is down it won't respond with a 502. Instead the user will see a busy mouse cursor until your back-end is up.
A user will be able to automatically "resume" their request after your app reloaded which is nice, it saves them from having to see a 502 and manually reload the browser but if you have a Rails app that takes 27 seconds to boot up then the user will be waiting for 27 seconds with no feedback. You could make a case the UX there is worse than a user explicitly seeing a custom 502 page that mentions to reload in a bit.
That's much different than a true zero downtime rolling update that something like Kubernetes will give you, or if you rolled your own solution to do it without Kubernetes. I don't know if MRSK will handle that, given the direction it's going it's quite possible DHH will implement that behavior in which case that would be very useful.
Rollback is also tricky once you start introducing database migrations. I personally always roll forward.
