An example using meteor-up would be:
You start the deployment process
A bundle is made locally and sent to the server
When the server has received it it starts the build process, which stops the current server
When the build is complete the server is started again
On our own product, when there’s no big db modification to run on startup the downtime is about 5-10 seconds. The client reconnects automatically and the window refreshes if necessary (if client code has changed). All in all this is a really fast and efficient way, but there are ways to improve things:
In our case users can write comments and stuff, reloading might wipe everything they were writing, so saving the content of an input into a session variable for example and putting it in again after a reload helps. Conceptually I mean caching the state of certain elements into something that can survive a hot code push.
There’s also the possibility to use something along the lines of grounddb: https://atmospherejs.com/ground/db
When the client goes offline he can still work with ‘grounded’ databases. After he reconnects the data modifications and methods are simply resumed and sent to the server.
All in all, deploying new versions of a meteor app is a smooth experience and there are always ways to decrease the problems it might cause to users.