[web-devel] Deploying a yesod app to production, without compiling in production servers.

[Greg Weber]

I don't see any downside to this strategy other than you need a good network
connection between staging and production:
Make staging and production exactly the same with respect to installed
binaries. After done testing on staging, compile for production on staging.
Copy the binary from staging to production (along with any required
assets).

Greg Weber

On Thu, May 12, 2011 at 7:28 AM, Nubis <nubis at 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 :)
>
>
> _______________________________________________
> web-devel mailing list
> web-devel at haskell.org
> http://www.haskell.org/mailman/listinfo/web-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/web-devel/attachments/20110512/ec86dc13/attachment.htm>