Hacker News Reader

Comment by eikenberry | Hacker News Reader

I don't understand the deployment section. Go has the simplest deployment I've ever had the pleasure to use. You compile the binary and copy it up. Static binaries make it so simple as to be trivial.

View on HN

First, if you use C libraries, you can't just compile on OS A and copy to OS B. I'm not 100% sure but while Go has much better cross-compiling story than others, I believe net/http does uses OS's C library and therefore cannot be cross-compiled that easily.

Also, you have to copy the assets (templates and such) and if you're deploying a new version of a web app, you don't just overwrite the binary. My script makes sure that if something goes wrong (i.e. a new version doesn't work or has a bug), it's easy for me to revert to previous version.

That being said, none of that implies that Go makes deployment harder (or easier, for that matter) than deploying code in other languages would be. It's pain in the ass but nothing that I couldn't solve in a day with a script written with Fabric.

>I believe net/http does uses OS's C library and therefore cannot be cross-compiled that easily

For whatever it's worth, I think CGO is only needed for native DNS resolution. If you (cross-)compile with CGO_ENABLED=0, then net/* will fall back to a pure Go DNS resolver, for which the only requirement is a valid /etc/resolv.conf on the target system.

My script makes sure that if something goes wrong (i.e. a new version doesn't work or has a bug), it's easy for me to revert to previous version.

Isn't that the point of version control? Any DVCS makes that easy to do.

The point is that there is an existing application in production and a new application is being deployed. If the deployment fails, it simply does not enable the new application, leaving the existing one running. Using version control to rollback a running application is inadvisable (yet quite common).

We deploy all the libraries with the application server in a directory called lib. Just throw LD_LIBRARY_PATH=lib before the command line. That will make sure you environment is the same wherever you go. You can also compile with -static if you want to go that route. As for rollback, make your deployment script upload binaries to a directory named the same as the revision it was built from and the symlink it in to place.

What about dependencies? Client-side resources such as .js and .css files, configuration files maybe, migrating the data even? A web app is (virtually) never just its server side code.

I wrote gobundle[1] as one solution to this.

[1] https://github.com/alecthomas/gobundle

That's very interesting! Do you just append the bundles to the executable and then have it read itself? I didn't look at the code, admittedly.

It generates Go code which is compiled in to the package.

The original article didn't discuss deploying assets, only the app/code. I suppose that might have been implicit, but I typically handle them separately.

Reply on news.ycombinator.com