For our backend, we deploy it as a nix package on NixOS, so we can atomically rollback the deployed code, as well as any dependencies like system libraries. Right now this requires SSHing into each of our two backend servers and running a command.
If it’s not urgent we’d just revert with a PR though and let the regular deploy process handle it.
The frontend we deploy with Heroku, so we deploy with the rollback button or Heroku CLI. Unfortunately we don’t have something setup where the frontend checks if it’s on the correct version or not, so people will get the bad code until they refresh
> For our backend, we deploy it as a nix package on NixOS, so we can atomically rollback the deployed code, as well as any dependencies like system libraries
Same for us, but we use nixpkgs directly over CentOS. Nix is perfect for rollback. It can be done on an entire cluster in seconds.
For the DB, We use schemaless DBs with Devs that care about forward and backward compatibility.
Oh, I forgot to add since many people mentioned this: we currently have nothing in place to automatically rollback migrations. So far that hasn’t been an issue, though.
If it’s not urgent we’d just revert with a PR though and let the regular deploy process handle it.
The frontend we deploy with Heroku, so we deploy with the rollback button or Heroku CLI. Unfortunately we don’t have something setup where the frontend checks if it’s on the correct version or not, so people will get the bad code until they refresh