3 ms·

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

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.

dmit 14y ago
>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.
icebraining 14y ago
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.
- Nagyman 14y ago
  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).
Negitivefrags 14y ago
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.

dmit 14y ago

>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.

icebraining 14y ago

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.

Nagyman 14y ago
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).

Negitivefrags 14y ago

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.