Best practice for updating Go web application

I am wondering what would be the best practice for deploying updates to a (MVC) Go web application. Imagine the following scenario :

1. Code and test some changes for my Go Web Application

2. Deploy update without anyone currently using the previous version getting interrupted.

I don't know how to make sure point 2) can be covered - when somebody is sending a request to the server and I rebuild/restart it just in this moment, he gets an error - even if the request just uses a part of the code I did not touch or that is backwards-compatible, or if I just added a new Request-handler.

Maybe I'm missing something trivial or a well-known pattern as I am just in the process of learning go and my previous web applications were ASP.NET- or php-applications where this was no issue as I did not need to restart the webserver on code changes.

It's not just an issue with Go, but in general we can divide the problem into two separate ones:

1. Making sure current requests do not get terminated and affect user experience.

2. Making sure there is no down-time in which new requests cannot be handled.

The first one is easier to tackle: You just don't violently kill your server, but tell it to exit, causing a "Drain phase", in which it does not accept new requests and only finishes the currently running requests, and exits. This can be done by listening on signals for example, and entering the app into a special state.

It's not trivial with Go as the default http server doesn't support shutting it down, but you can start a server with a net.Listener, and then keep a reference to it an close it when the time is due.

Now, doing only approach one and then starting the service again will cause new requests not to be accepted while this is going on, and we all know this can take a number of seconds in extreme cases.

So what we need is another instance of the server already running with the new code, the instant the old one is not responding to new requests, right? That can be done in several ways:

1. Having more than one server, and a load-balancer on top of them, allowing one (or more) server to take the load while we restart another. That's the simplest way, and the way most people do it. If you need N servers to take the load of your users, just keep N+1 and restart one at a time.

2. Using socket sharing tricks. In Newer Linux kernels, Many processes can listen and accept on the same port. What you do is simply start the new instance and then tell the old one to finish and exit. This way there is no pause. This is done by setting SO_REUSEPORT on the listening socket.

3. The above can be automated with ready to ship solutions, like Einhorn, that deals with all the details for you, see https://github.com/stripe/einhorn

4. Another approach is documented in this blog post: http://blog.nella.org/?p=879