For security reasons, I would strongly recommend against compiling (or even having anything remotely resembling a compiler) on your production server.  For that reason, you should probably also leave it off of your staging server (apt-get remove build-essential)  :) 

That said, the easiest long-term way to manage binaries in a production environment is to statically link.    If your enterprise is successful, chances are you'll move on to other products/projects and the older products will still be running on those machines, but you will have likely upgraded your development environment (especially when using Haskell) .   It is easiest to minimize your dependencies on .so's.  Just my $.02 

On Thu, May 12, 2011 at 10:28 AM, Nubis <nubis@woobiz.com.ar> wrote:

Hi guys,
After lots of effort, the yesod app I'm working on is finally ready to be deployed in a production environment, but I'm having a hard time deciding what's the best strategy to do so.
I have proper development, staging and production environments. We'll be doing our coding on development, then tag a revision and push it to staging, and then if
everything works fine we'll push that same tag to production. We're going to be using ubuntu 11.04 and all machines will be the same architecture too.
My main concern is that compiling in production may be inefficient and badly stress the server, so these are my deployment options so far, I would like to hear your opinions on them,
and maybe you can also answer some of the questions that arise from them:

* Compile and statically link the app, then push it to staging, and if it works, to production:
    Would be great, but I'm getting some warnings relating glibc and errors linking libgss which I could fix, but hint's that It's going to be painful to keep a statically linked version and suggest it's going to be brittle.

* Compile and move the binary and all the libraries it uses to the server:
   In theory it should work, but I'm not sure which libraries or library directories I should move/rsync. I'm also worried this way of doing it could be brittle since I could add dependencies that install stuff
in different places and forget to add them which would mess up my deployment process a bit and require further manual intervention.

* Compile on the server: It's really convenient since I could copy the source to the server and do a cabal-install there, but I'm afraid it will stress the server too much while compiling (granted, won't be often on production), but also keeping ghc and cabal on the server requires the extra work of keeping them up to date in an unobtrusive fashion. I tend to break my ghc install rather frequently, I wouldn't like to find myself logging in to production to fix a broken ghc/cabal/haskell platform install.

Thanks for your advice, also let me know if you think I'm too much of a slacker, unlucky, or worrying too much about nothing.

cheers
----nubis :)